VD>Кстати, я тоже не вижу каких-то недостатков в битовых полях. Иногда вещь очень удобная. Хотя и заменимая с помощью разных BitArray-ев и ООП. В общем, если с битами возиться не часто, то битовые поля не очень нужы. Но хуже от них не было бы.
Как драйверист скажу — битовые поля противны. Намного удобнее константы битовых позиций. Например, если надо сразу какое-то состояние из нескольких бит куда-то присвоить.
Одно дело
w->CommandBit = 1; w->ModeBit = 1;
и другое
w |= ( COMMAND_BIT | MODE_BIT );
Все состояние пишется в одну строку, удобочитаемо.
Вдобавок очень часто надо сначала в памяти сформировать слово, а потом его закинуть в железку. Через константы — элементарно, через битовые поля — уродство вида
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
A>>Если не секрет, не поделишься, откуда ноги у этих сказок про working set растут? Не в том смысле, что working set — это все сказки, а в том, что "дерни за SetProcessWorkingSetSize — working set уменьшится, и наступит счастье". Я уже не раз встречал подобное заблуждение, очень распостраненное на рсдн'е.
VD>Про щастье я не знаю. Это не по адресу. Я просто продемонстрировал, что реально требуемая память значительно меньше чем то что занимается процессом в целях повышения производительности.
Вот это и есть сказки. Смотри vadump'ом, где там реальная память. Получишь число близкое к virtual memory из task manager'а. А то, что ты продемонстрировал, это как отправить память процесса в swap.
A>>Параметр показываемый TaskManager'ом, который тебя должен интересовать, это virtual memory.
VD>Это почему? Мне что виртуельного места в пэйдж-файле жалого что ли? Пока памяти в системе хватает этот параметр ровным счетом ничего не значит.
Это значит, что тебе нужно гонять страницы памяти в swap и обратно.
A>> И это будет набор memory pages, доступных для процесса (вне зависимости от их расположения в памяти или в page file). Как ты понимаешь virtual memory нельзя "уменьшить" такими трюками вроде SetWorkingSetSize. Вся память, которую, твой процесс затребовал, она вся здесь и никуда от нее не деться.
VD>Я вот не очень понимаю каой вообще смысл рассуждать о виртуальной памяти? Меня как раз интересует та часть памяти которая реально используется процессом.
Смотри в vadump, если хочешь узнать, какая память реально используется процессом. Если твой процесс выделил 10 мег, а потом OS отправила 5 из них в swap, пользователю от этого не легче. Процесс имеет все те же 10 мег, 5 из которых лежат в swap'е. И когда процесс их захочет почитать, то у него не только page fault будет, но и все что в этом случае полагается.
VD>Надо же понимать, что ЖЦ принципиально занимает заранее большой кусок и в дальнейшем использует его последовательно. ОС же при этом обеспечивает распределение процессам физических страниц памяти. Проблемы с памятью или производительностью могут быть только если нехватает физической памяти и ОС приходится постоянно поднимать и сбрасывать в своп данные.
Неверно. GC отнимает столько, сколько ему нужно. А как только он за-commit'ел эту память — всё, OS с ней ничего не может поделать. Он обязат выделить процессу реальные страницы. Потом OS, конечно может отправить эту память процесса в swap, но от этого уже не легче. Как только таких прожорливых процессов набирается штуки две-три, swap становится постоянно задействован.
VD>[рассуждения о кошерности VM поскипаны.]
A>>Теперь нам ясно, какой параметр нам нужно стараться уменьшать. Это, во-первых, private memory. Из managed кода, это значит, что нужно меньше выделять самому и меньше использовать всякие фичи, которые любят выделять/писать в память. Еще неплохо пользоваться NGEN'ом, чтобы избавиться от необходимости JIT'а, который динамически создает код, весь попадающий в private категорию.
VD>На практике ngen ничего не дает. Ни по памяти ни по скорости. Дает он только небольшое увеличение скорости загрузки модуля.
А ты думаешь, почему увеличивается скорость загрузки? Меньше памяти требуется.
VD>[рассуждения про разреженность метаданных тоже поскипаны это такие копейки, что о них и говорить не стоит]
Ха! Сразу видно профессионала
A>>Чтобы увидеть, где у тебя в процессе эти private, shared & sharable, нужно использовать vadump.
VD>А зачем мне смотреть на дамп виртуальной памяти?
VD>Еще раз попытаюсь объяснить. Объем знятой но не испльзуемой приложением папяти никак не влияет на производительность (по крайней мере в ОС семейства NT). Значим только тот объем физической памяти который постоянного используется процессом. Если моя программа занимает 100 мег виртуальной памяти, а использует из нее 5, то все затраты сводятся к выделению 100 мег памяти и отображению их на пэдж-файл (если это вообще не ДЛЛ). Время уходящее на заем виртуальной памяти не вилеко, но ощутимо. Время же на назначение и сброс страниц (если в них не ведется записбь) крайне мало.
Если OS выделила для твоего процесса 100 мег и они отобразились у тебя в графе virtual memory, то твой процесс хоть раз пошел и прочитал/записал в эти 100 мег. А если так, то OS не может просто эту память покоцать. Она отправляется в swap, те записывается на диск (если конечно это не file-backed memory).
VD>Точно так же и дотнетный экзешник. Если есть море неиспользуемой памяти, то ворксет будет приближаться к объему закомиченой памяти.
virtual memory — это как раз и есть то, что ты закоммител. working set — это то, что ты имеешь в физической памяти из того, что ты закоммител.
>Но как только системе понадобится память, она сразу же отберет ненужные области и отдаст их другим процессам.
Она не отберет, а отправит память в swap. И диск затарахтит... (Это я к тому, что ты, наверное, думаешь, что данная операция дешева. Отнюдь.)
VD>Реальное дотнетное приложение просто не отдает память системе рассчитывая на то, что если что та сама справится с отемом.
VD>Хороший полигон для наблюдения за памятью является Янус. В работе он может занимать 60-80 мег оперативки, но стоит свернуть его и развернуть обратно как он нчнет занимать 12-25 мег.
Это не значит, что остальные мегы не являются закоммиченными. Процесс их все равно имеет. Как только он захочет к ним обратиться, OS подгрузит эти старицы с диска.
>Причем рост памяти особо идти не будет. Но стоит попереключаться по форумам, поткрывать окна, как память снова достигнет максимума, вот только произойдет это очень не быстор. Единственный быстрый способ занять сразу много памяти — это произвести поиск по всем фомурмам. При этом, правда, дотнет будет вообще не причем, так как поиск целиком осуществляется средствами Jet-а, но MV и ворксет поднимутся до максимальных величин. И опять же банальная минимизация сбросит ворксет в копеечные величины.
VD>К чему я все это рассказываю?
Все твои рассуждения — это все равно, что сказать: "а нефиг, page file большой, виртуальной памяти-то вон сколько!"
>Дело в том, что то что многие воспринимают за ужасную прожорливость дотнетных приложений на самом деле является самым разумным способом управления памятью в ОС семейства NT. Если памяти хватает, то операции на управление ею минимизируются. Если же ее становится недостаточно, то она переодически отнимается у дотнет-ых прцессов и отдается другим. Именно по этому дотнет больше всего поражает воображение обладателей огромных объемов памяти. Запусти то же приложение в стесненных условиях и оно начнет расходовать память намного экономнее, но эффективность от этого упадет. Все вместе это называется эффективным автоматическим управлением памятью. И не нужно пугать этим неосведомленных людей.
Ужасная прожорливоть .NET приложений — это оно самое и есть. Чудес не бывает. OS, конечно, может за счет виртуальной памяти создать впечатление, что ее гигабайты, но факт остается фактом, .NET приложения требуют мегы памяти, которые OS периодически выгружает в swap, а потом обратно подгружает по мере надобности. И диск тарахтит...
Здравствуйте, slegkapjan, Вы писали:
Д>>то есть — если использовать std::istream вместо ручного разбора данных, то это будет работать быстрее и отнимать меньше памяти? S>N.B. Вообще, потоковая система STL написана из рук вон плохо. Даже при чтении одного байта через istream::get() вызвается огромное количество (в том числе и виртуальных функций), что приводит к очень большой потере производительности.
Это цена за гибкость и расширяемость. Пример: мне недавно понадобилось utf-8 файлы читать. Код элементарен до безобразия:
Причем, utf-8 это не какая-либо особенная кодировка, для которой есть специальная поддержка. Таким же образом я бы мог прикрутить поддержку для любой другой кодировки. Покажи мне другую библиотеку, где данная операция обходилась бы так же легко.
>В этом смысле, <stdio.h> и FILE* практически идеальное решение. Единственное, что лично меня не устраивает в FILE * -- это отсутствие возможности подключать эту библиотеку к своим потокам, поэтому, например, если нужно дать возможность программе считывать данные из сжатого файла как из обычного, приходится переходить на свою доморощенную потоковую библиотеку.
VladD2,
> ПК> Несколько не в тему, т.к. C++, действительно, поддерживает несколько парадигм (стилей, как выразился в данной статье Страуструп). И авторами языка, в отличие от тебя и твоих заявлений, C++ к ООП не сводится.
> Ну, почитай свою статью внимательно. Там только об ООП речь и идет. Чуть чуть затрагивается вопрос дженерик-программирования, но это как бы к парадигмам и стилям отношения не имеет. <...>
Имеет. Самое непосредственное. Не хотелось оттуда ничего цитировать, т.к. copy-paste не работает, но хоть начало для полноты картины набью:
C++ directly supports a variety of programming styles. In this C++ deliberately differs from languages designed to support a single way of writing programs. This paper briefly presents key programming styles directly supported by C++ and argues that the support for multiple styles is one of its major strengths. The styles presented include: traditional C-style (1), concrete classes (2), abstract classes, traditional class hierarchies (3), abstract class hierarchies and class hierarchies (4), and generic programming (5).
> В общем, не нужно выдавать свои желания за действительность. С++ пытается позволять писать в разных стилях, но рассчитан он в основном на два: структурный и ОО.
Конкретные классы с их собственным наследованием и прочими "удобствами", для них созданными, куда отнесем? Взаимодействие иерархий (конкретных) классов с иерархиями абстрактных классов куда? Generic programming куда?
> И в этом свете ОО-дизайн является (должен являться) главной стратегией проектирования ПО.
В общем случае — не является, не должен. Там где надо — да, является. Но далеко не везде. Во многих случаях значительно более эффективным (с точки зрения разработки, дальнейшей расширяемости и т.п.) является использование альтернативных подходов. Еще более удачной — их комбинация.
> GOF, насколько я помню, использовал С++ в качестве одного из основных языков примеров.
Ну и что? Это только говорит об адекватной реализации одного из непосредственно поддерживаемых стилей программирования. Это не означает недостаток поддержки или вторичное положение других стилей.
> ПК>2) Твое последующее утверждение: > ПК>
> ПК>Ну, то есть ФП в нем поддреживаться так же как ООП? Или язык не является ООЯ?
> ПК>
> ПК>Тоже к делу отношения не имеет, т.к. ФП к числу поддерживаемых C++ парадигм (стилей) не относится. > > А какие же еще парадигмы тогда поддерживает С++?
Читай цитату в начале данного сообщения. Специально цифирками обозначил.
> И в чем тогда заслуга С++ если почти на любом языке можно писать в разных стилях?
В полноте поддержки каждого из стилей. В C++ можно спокойно писать в процедурном стиле, не заботясь о борьбе с OOP. Можно, наоборот, писать в OO стиле, не симулируя его искуственно. Можно писать в generic стиле. И т.п. Можно сочетать все вместе. "Почти любые" языки этим похвастать не могут.
> Ну, и главно как это отражается на порании принципов ОО-дизайна?
Еще раз: OOP является одним из поддерживаемых стилей, не единственным, и даже не главным. Никто ОО-дизайн не "попирает", т.к. для начала в C++ его на пьедестал не возводили. Когда выгодно — используют; в этом случае все нужное для комфортной работы язык предоставляет. Когда не выгодно — не используют; в этом случае язык со своими "ОО" ограничениями под руки не лезет. Все дела
> ПК> Все.
> Что все?
Перечисленные два пункта — все, что я имел в виду. Ты об этом в предыдущем сообщении спрашивал.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Влад, не разыгрывай дурачка, пожалуйста, очень неприятно общаться в такой манере.
VD>Ну, тогда и ты не разыгрывай. А то смешно слышать о том, что лики видите ли тут не причем. Что по-твоему будет если выполнить подобный код: VD>
VD>int main()
VD>{
VD> A * b = new B();
VD> delete b;
VD>}
VD>
VD>???
VD>Незнаю кто ты в своих проектах (рядовой программист или отвественный за релиз менеджер), но я в доволь насмотрелся на подобные вещи и на слушался, что ошибиться так очень сложно. Ради оптимизации (причем очень сомнительной) народ еще не такое накручивает.
вот объясни, пожалуйста, кому в здравом уме понадобилось писать то объявление b, которое ты привел, и какие цели такое объявление может преследовать.
Приведи хотя бы одну разумную причину, по которой нужно писать A * b = new B();, а не B * b = new B();
Оптимизации тут, очевидно, никакой нет.
Я только еще раз могу повторить, что такоенаписать довольно сложно и я таких ошибок видел в реальной жизни (в сымсле, в промышленном коде) очень мало. В основном это — результат copy-paste'а, ну а copy-paste'ом можно еще и не такие баги посадить.
Здравствуйте, VladD2, Вы писали:
VD>Ну, прямо крик души притесненного и обделенного таланта. А я вот не считаю, что все места занимаются разными долболомами, а умным и правильным места не дают. И боюсь, что если этим самым умным и правильным (по их самомнению) доврить работу тех самых "котов", то вместо продукта будет полный абзац, а юзеры будут выслушивать объяснения почему, видите ли, GPF лучше сообщения об ошибки с возможностью продолжения.
интересно... А в самом деле, почему? Пусть объяснит!
VD>Извини, но программы валятся и глючат не от недостатков проектирования. Это в оснвовном ошибки кодеров. Вот таких уверенных как ты. Для которых язык ничего не значит, а все ошибки от кривых рук.
Представьте себе язык Judъ, где нет массивов, и есть только указатели (т. е. нельзя объектную переменную обхявить, можно тлько указатель на объект объявить и нет способа отличить массив объектов от указателя на 1 объект.
Представим другой язык Apple (раздора ессесно ), в котором есть массивы и ссылки (не только на объекты но и на value-примитивные типы), но вообще нет указателей.
В каком языке больше "ранг ошибаемости"? Правильно — в Judъ (Жудъ). Так что утверждать что язык не имеет значения, бессмысленно.
Это всеравно, что говорить "Какая разница, на каком автомобиле принять участие в формуле1? Всеравно доедем до финиша!".
ГВ>>И распространение управлямых сред типа Java/.Net ситуацию не улучшит, а только ухудшит. Одно хорошо — stack trace станет просто ординарным явлением, а не предсмертным криком программы.
VD>Уже улучают. Янус по крайней мере работает. А хваленые версии которые должны были летать, так и не появились на свет.
Дело не в янусе, а в принципе. Имхо, управляемая среда даёт за счёт рантайм-проверок (реализуемых в таких средах проще, чем в обычных, а некоторые проверки вообще не реально сделать в неуправляемой среде), повышение безопасности и конфиденциальности данных. И мне это нравится, правда пока секурити на уровне объектов ещё не ввели (я тут гдето "спецификацию DreamOS" цитировал, по этим словам можете найти, это было в текущем месяце). Но когда весь user applications layer будет managed, тогда можно постепенно свести к 0 потребность в хендлах, как явлениях "windows-природы", будь то денскриптор файла, HWND, Find*File-хэндлы....
Имхо, менеджед может быть всё, кроме ядра, роль которого будет играть тогда MSIL-machine.
VD>Ага. У МС 20 лет и их состояния не хватило построить цельную модель. Или ума. Жаль тебя не встретили. Сейчас бы глядишь работали на супер стабильном Ворде.
Который бы валился раз в год, не чаще, но волился бы так, что хоть проц и материнку новую покупай
VD>Да задолбал ты уже со своим продумыванием. Там баги. Баги кодеров, а не дизайнеров. А выловить их не могут, так как это ошибки третьего-четвертого порядка, и потому что вылезают они только при стечении некоторых абстаятельств. Ну, еще, возможно, из-за того, что разные средства проверки орфографии поставляются криворукими уродами на которых в МС сильно повлиять не могут. И тут бы очень помог бы вариант когда вместо GPF мне бы вылетело окно с кнопочкой Континьё.
Имхо, дизайнеры тоже люди Т. е. недочёты дизайна *щас меня бить будут...* просто играют роль каркаса для полипов багов, но только если язык склоняет к ошибкам.
У МС нет выбора — им приходмится привлекать сторонних девелоперов, и "devil-оперов", потому что ни одна организация в мире не способна содержать штат для локализации программ для всех 200 с пригоршней стран мира (я говорю олаколизации не столько ресурсов, сколько логики вроде проверки орфографии).
ГВ>>потому что "требования бизнеса"
VD>Ну, да... теперь уже бизнес мешает.
В бизнесе мешает только то, что его не интересует идеальное ПО, ео интересует ПО, которое можно сделать за реальное время и разумные заираты.
Представьте, сколько веков бы мы ждали виндовс для рабочих групп (3.11) если бы егшо хотели идеальным сделать). В этих условиях остаётся только создавать среды разработки и исполнения, минимизирующие как количество, так и ущерб от ошибок.
VD>Нефига сваливать проблемы на других. Ошибаются все! Это как закон всемирного тяготения, он неотвратим. Натура у человека такая. Он всегода ошибается. Именно ошибки и способность их анализировать сделали человека человеком. И слушать пургу про "других виновных" и "проблемы рынка" просто противно.
Респект в общем-то, но человека человеком сделал бог. А способность ошибкам есть следствие способности к эксперементу, к познанию. Обратная сторона медали, так сказать. Вот способность учиться на чужих ошибках делает его царём природы. Правда тираном, но это другой вопрос — вопрос этики/ культуры.
VD>Нужно думать о том, как повысить уровень программирования и создать гарантированных барьер хотя бы против самых болезненных ошибок. А не перекладывать отвественность на четри знает кого.
Супер! Соглсен! Двумя куками... ээ руками за!
VD>Притом что это багодром. Это средсво не только не защищающее от ошибок, но и порой подталкивающее к их совершению. Конечно дотнет или Ява не панацея. Конечно они не решат всех проблем, покрайней мере, в одночасье. Но это рельный и ощутимый шаг в правильном направлении.
Правда последний шаг в этом направлении будет ИИ-низированый генератор кода по постановке задачи, и тогда роль системных архитекторов будут играть аналитики, а роль кодеров — системные архитекторы.... Не знаю, является ли это архи, хорошо, если программирование вообще и кодинг как класс вымрут за ненадобностью....
Здравствуйте, jazzer, Вы писали:
J>И, судя по молчанию Андрея, он с этим согласился.
На самом деле, этот случай не так уж и важен. Есть намного более опасные грабли
Создавать иерархии классов без виртуального деструктора — просто "плохой стиль", вот и все.
А вообще — у меня создается впечатление, что 99% "защитников C++" в этой теме не знакомы с .NET, или знакомы очень слабо. Я бы посоветовал детальнее изучить его, чтобы иметь возможность сравнивать на деле, а не ругать его за "неэффективность" и "прожорливость".
С++ в свое время тоже немало за это ругали У .NET в плане эффективности тоже есть немало плюсов. Например, такой могучий инструмент оптимизации, как динамическая генерация кода в рантайме. Другой вопрос, что это пока что мало где используется эффективно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Об том и речь.
Факт в том, что .NET реально очень упрощает разработку по сравнению с плюсами. Это дает возможность тратить свое время на разработку добавочных фич и оптимизацию на высоком уровне, а не на борьбу с граблями и многочасовое ползание по программе дебаггером.
Если взять команду идеальных разработчиков во главе с идеальным менеджером, найти для них идеального беспроблемного заказчика — вероятно, тогда никакой разницы не будет. Но мы живем в реальном мире
Здравствуйте, Волк-Призрак, Вы писали:
ВП>И меньше гуйных ресурсов жрать будет, если показывать тоько то что на экране реально помещается, Хотя обработка и будет вестись по 1000*10000..... ВП>Странное решение, однако....
Просто не нужно подгружать все данные в память зараз, вот и все. Flyweight с пулом объектов, все данные остаются в исходном файле и подгружаются по мере необходимости. Неиспользуемые в данный момент объекты возвращаются в пул.
Даже если возникают проблемы с MMF, можно реализовать аналогичную технику вручную.
Прога будет работать как минимум не медленнее, чем вариант с загрузкой всех данных в память (ну не верю я, что прога используется только на машинах с 2гб оперативки ). При этом время загрузки данных уменьшится на порядки.
Ну да о чем это я... невиртуальные деструкторы — это куда увлекательнее
Здравствуйте, adontz, Вы писали:
A>Нет не правильно. На Си++ можно написать кроссплатформенное приложение, на C# нельзя. Это не только заслуга большого количества компиляторов (кстати используя GCC можно не менять компилятор на разных платформах), но и следствите большого количества кроссплатформенных библиотек.
Моно уже вышел в релиз, так что — welcome.
Что касается написания кроссплатформенных проектов на С++... честно тебе скажу, разработка кроссплатформенной версии на основе реального существующего продукта — это чудовищный объем работы. Особенно с учетом того, что документация по архитектуре — это что-то вроде синей птицы... все про нее слышали, но никто еще не видел
Если проект сразу закладывается с учетом переноса на другие платформы — тогда немного проще, но:
1. Это встречается крайне редко, посколько требует дополнительных затрат и нет никакой гарантии, что эти затраты вообще когда-нибудь окупятся
2. Все ошибаются.. и пока дело не дойдет непосредственно до процесса портирования, разработчики успеют наворотить кучу платформо-зависимых мест
Например — продукт одного очень известного российского производителя (известного не только в нашей стране). Используется собственная библиотека классов, никакой завязки на платформу — в общем, сказка, а не программа. По крайней мере, в теории.
Но вот дело доходит до переноса проги под другую ОСь... и тут выясняется, что вся сериализация в проге делается очень просто — указатель на объект приводится к void*, после чего его содержимое тупо сбрасывается в файл. Десериализация — по тому же принципу. Плюс к этому — огромное количество алгоритмов, завязанных на конкретный размер типов. Плюс к этому — прямые вызовы API из кода программы, несмотря на все запреты и контроль. Инициализация переменных, которая завязана на определенный порядок вызова конструкторов. Проект — огромный и очень сложный. Вся документация состоит только из комментариев в коде.
И тут начинается такое, что даже немецкая порнушка покажется невинным развлечением
Hello, Дарней!
You wrote on Tue, 28 Dec 2004 08:53:16 GMT:
Д> Просто не нужно подгружать все данные в память зараз, вот и все. Д> Flyweight с пулом объектов, все данные остаются в исходном файле и Д> подгружаются по мере необходимости. Неиспользуемые в данный момент Д> объекты возвращаются в пул. Даже если возникают проблемы с MMF, можно Д> реализовать аналогичную технику вручную.
Если в этом месте опять возникнут проблемы с памятью — я так и сделаю. А
горбатиться и реализовывать все, что ты тут расписал, когда в этом нет
необходимости, мне лень.
Д> Прога будет работать как минимум не медленнее, чем вариант с загрузкой Д> всех данных в память (ну не верю я, что прога используется только на Д> машинах с 2гб оперативки ).
При чем здесь 2 Гб?
Д> При этом время загрузки данных Д> уменьшится на порядки. Ну да о чем это я... невиртуальные деструкторы - Д> это куда увлекательнее
Оно не увлекательней, оно бесплатно. Закомментарил одну строчку, другую
сделал protected — и 5% памяти сэкономилось. Вот пулы писать действительно
куда увлекательней.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 delta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, jazzer, Вы писали:
J>>И, судя по молчанию Андрея, он с этим согласился.
Д>На самом деле, этот случай не так уж и важен. Есть намного более опасные грабли :)
Есть, кто ж спорит :)
Д>Создавать иерархии классов без виртуального деструктора — просто "плохой стиль", вот и все.
Предлагаешь пойти по второму кругу? :)
Д>А вообще — у меня создается впечатление, что 99% "защитников C++" в этой теме не знакомы с .NET, или знакомы очень слабо. Я бы посоветовал детальнее изучить его, чтобы иметь возможность сравнивать на деле, а не ругать его за "неэффективность" и "прожорливость". Д>С++ в свое время тоже немало за это ругали ;) У .NET в плане эффективности тоже есть немало плюсов. Например, такой могучий инструмент оптимизации, как динамическая генерация кода в рантайме. Другой вопрос, что это пока что мало где используется эффективно.
Дарней, ткни меня, пожалуйста, носом в мое сообщение, где бы я ругал .NET или сравнивал его с С++.
Топик изначально был о С++, а не о .NET.
Еще раз повторю, у меня нет никаких претензий ни к самому .NET, ни к программистам на .NET, в том числе и перешедшим туда из С++ :). Но когда утверждают, что на С++ невозможно програмировать, потому что есть .NET — извините, не мне одному отлично удается на нем программировать, не испытывая никаких проблем. Называйте меня кем хотите, но я привык к С++ и мне с ним легко и удобно, так что пока за С++ платят деньги — я буду работать на С++.
Здравствуйте, jazzer, Вы писали:
J>Еще раз повторю, у меня нет никаких претензий ни к самому .NET, ни к программистам на .NET, в том числе и перешедшим туда из С++ . Но когда утверждают, что на С++ невозможно програмировать, потому что есть .NET — извините, не мне одному отлично удается на нем программировать, не испытывая никаких проблем. Называйте меня кем хотите, но я привык к С++ и мне с ним легко и удобно, так что пока за С++ платят деньги — я буду работать на С++.
А мне, честно говоря, стало просто противно писать на С++. Приходится тратить кучу времени на совершенно элементарные вещи.. и отнимать это время у других, более важных, задач
Хотя временами без него не обойтись. Необходимость устанавливать фреймворк — слишком большой минус для некоторых случаев.
Здравствуйте, alexeiz, Вы писали:
A>Причем, utf-8 это не какая-либо особенная кодировка, для которой есть специальная поддержка. Таким же образом я бы мог прикрутить поддержку для любой другой кодировки. Покажи мне другую библиотеку, где данная операция обходилась бы так же легко.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, jazzer, Вы писали:
J>>Еще раз повторю, у меня нет никаких претензий ни к самому .NET, ни к программистам на .NET, в том числе и перешедшим туда из С++ :). Но когда утверждают, что на С++ невозможно програмировать, потому что есть .NET — извините, не мне одному отлично удается на нем программировать, не испытывая никаких проблем. Называйте меня кем хотите, но я привык к С++ и мне с ним легко и удобно, так что пока за С++ платят деньги — я буду работать на С++.
Д>А мне, честно говоря, стало просто противно писать на С++. Приходится тратить кучу времени на совершенно элементарные вещи.. и отнимать это время у других, более важных, задач :crash: Д>Хотя временами без него не обойтись. Необходимость устанавливать фреймворк — слишком большой минус для некоторых случаев.
