Здравствуйте, VladD2, Вы писали:
VD>Действительно ламерский. Но не в том смысле что стыдно этого не знать, а в том, что подобные вещи в гугле за пол минуты найти можно: Flyweight GOF.
Дык если я ламер, то в ламеризме разбираться должен. как испытывающий его на собственной шкуре, или нет:?
Здравствуйте, VladD2, Вы писали:
ГВ>>SVN написан на pure C (около 800 файлов). Только COM и Java-binding содержат чуть-чуть C++ (~20 файлов). Статистика по версии 1.0.9.
VD>Точно на С то тоже ламеры пишут. Ну, найди бокрепорт любого С++-ного софта сравним количество мемориликов и неинициализированных переменных с Янусом.
Не скажу насчёт формального багрепорта, но в Янусе нередко возникает ошибка transaction deadlock. И... хммм... не помню даже, какие причины — но, в общем, stack trace где-то с регулярностью раз в два дня я получаю. Возможно, что причина в Jet. Честно говоря, даже внимание обращать перестал. Некий уровень глючности программе прощается, поскольку она:
а) Несомненно удобна;
б) Данные пока не теряла;
в) Единственный оффлайн-ридер для RSDN (News-ами я пользоваться не люблю);
г) Я вообще очень толерантный пользователь.
К слову сказать, 1.1.4b3.185 гораздо лучше, чем 1.1.3.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
A>>Ошибка данного типа не является ошибкой из серии "ах, опять оплошал!" Она не допускается случайно. Наоборот, это сознательное действие, объяснимое только отсутствием необходимой квалификации. VD>Тут выше замечательно описано как народ готов плевать на подобне ошибки ради 5%-ного выигрыша в паяти.
Меньше надо на мозги людям фигнёй капать. Вот они и будут больше и чаще думать.
VD>ЗЫ
VD>Постоянно слушу от поклонников С++ фразу "Квалифицированный программист должен" или "это делают неофиты" ну и т.п. И не разу не слышал о том, что вот проблемы у нас в проекте.
Дык, если я, например, начну говорить о проблемах в проекте, то всё сведётся к менеджменту, а не к языкам. Причём тут языки? Это технические проблемы, которые совсем не сложно решить. А вот примеров идиотских менеджерских решений, из-за которых можно смело потом идти и обвинять C++ (VB, SQL, ...) во всех смертных грехах привести можно сколько хошь. Простейший, это "не трогайте этот кусок кода, потому что он УЖЕ ОТЛАЖЕН! А-а-а-а!", даже если с этим куском кода работать становится невозможно — стоит колом поперёк логики и хоть ты тресни. Ты тут вспомнишь Задорнова, а я с тобой соглашусь — да, они тупые с точки зрения техники реализации. И воспитывают таких же тупых пользователей. Ну и причём тут языки?
С другой стороны пользователям тоже особо делать нечего. Как, например, никуда не деться от того, что кроме Janus удобного офлайнового ридера нет. Да, я знаю, что проявляю тупость и беспринципность. Поверь, был бы другой ридер — менее глючный и столь же удобный, сменил бы его с радостью. Даже денег, наверное, дал бы за копию. Но только, если он не будет тренировать моё терпение и развлекать stack dump-ами (AVP-окнами, как вариант).
VD>Все таки замечательно. Но как не глянешь в форум по плюсам, так там одни проблемы. У меня возникает впечатление, что те кто защищает С++ в этом форуме и те кто пишет на нем неальный софт — это разные люди.
Неправильное у тебя впечатление. Потому что те, кто "защищает C++ на этом форуме" и "пишет на нём реальный софт", как правило, отвечают, а не жалуются в форуме по C++. Разницу видишь?
VD>Так же забавно, что вокруг столько крутых С++-программистов, в разные MS, Quark, Adobe, Corel (далее следут список из сотен, а то и тысяч успешных IT-компаний) берут исключительно ламеров, потому как у всех и нуих продукты глючат так что плакать хочится. И по какой-то уж совсем не объяснимой причине все эти продукты написанны на С++.
Влад, поверь, даже одного балбеса может оказаться достаточно. Другой вопрос, как именно этими балбесами становятся. Вернее — как из нормальных людей крупные организации делают идиотов. Впрочем, это уже тема отдельного форума.
Кстати, та же Corel, вроде бы, пыталась свой пакет на Java переписать. Гы... 7-я, что ли, версия была... Не помню. В итоге вернули всё взад, AFAIK.
VD>Нет, бесспорно, и на С++ и даже на С можно написать устойчивый и относительно надежный софт. Причем до недавнего времени это даже было обсалютно оправдано. Но стоимость доведения софта написанного на С++ до качественного состояния настолько велика, что даже монстры позволяют себе тратить такие суммы только на флагмансткие продукты вроде СУБД и OS.
Почему-то я уверен, что дай им волю "нарушить правила здорового консерватизма" и мы быстро узнаем, что такое SQL-recordset, состоящий из строчек stack dump-а. Это как раз тот случай, когда корпоративные правила работают на благо общества.
VD>А в это время представители мелких никому не изместных компаний говорят, что проблем нет в принципе и мол всего лишь нужно брать на работу их родимых.
VD>Кто-нибудь может объяснить этот парадокс? Что вы откажетесь пойти на работу за 70 килобаксов в год в какой-нибудь Adobe?
Хех. Не смеши такой риторикой. "Пойти на работу за 70K$ в год" и "препроектировать продукт" в компании калибра "какого-нибудь Adobe" — суть две большие разницы. Почему, понятно? Если не понятно, то объясню.
"Пойти на работу" — это всего лишь устроиться одним из десятков исполнителей низшего звена. В лучшем случае — уровня team lead команды по разработке какого-нибудь визуализатора отдельно взятых овалов на устройстве с разрешением 1024x768 и менее. Или какая-нибудь подобная чушь.
А перепроектировать продукт... Ну ты что! Это же, млин, честь великая, достойная Наполеона местного масштаба. Это же сразу десяток менеджеров закладывать в бюджет нужно! Так что, те самые представители "маленьких компаний" как тот кот из анекдота: "зъисть-то он зъист, да хто ж ему дасть!" на то есть проверенные коты, которые жрут умеренно и время от времени успокаивающе мурчат за печкой (на собраниях). Дальше о глюке феномена "доверия к проверенным кадрам" рассказывать или сам догадаешься?
VD>Или может быть Adobe вам не верит? А то я смотрю как валится In Design 3.0 и тихо фигею. А от того как Ворд вылетает уже и фигеть перестал.
А я вот, уже давно ни отчего не фигею. Привык, что несмотря на рассуждения о необходимости "правильно" проектировать, программы как писали через ж... так и будут писать. И виноватых не сыщешь, потому что у всех есть разумные и логичные оправдания. Одни боятся гнева клиентов, другие — гнева боссов, третьи — непосредственных руководитей, четвёртые никого не боятся, но никого и не слушают и т.п. И распространение управлямых сред типа Java/.Net ситуацию не улучшит, а только ухудшит. Одно хорошо — stack trace станет просто ординарным явлением, а не предсмертным криком программы.
VD>"Ламеры" и "нишей" МС вместо того чтобы убрать вылеты Ворда придумали вочер который ловит крах ворда и спасает его память. После перезагрузки по этой памяти воссоздается файл (зачастую тоже битый). Ну не смешо ли это?
Влад, вот давай, не будем путать "как надо" и "как делают"? Потому что надо:
— строить цельные модели (за очень небольшие деньги могу тебе немного рассказать на эту тему );
— продумывать их до реализации;
— поменьше суетиться и лизать одно место начальству.
А происходит "как всегда": менеджер принял техническое решение; балбес-архитектор залудил полупродуманную фичу, потому что "требования бизнеса" (фетиш наш драгоценный, мать его трижды за ногу); взяли насквозь сертифицированного программиста, которому похрену, что будет на выходе — лишь бы начальство удовлетворить; взяли хорошего программиста, но объяснили, что думать вредно, а "нада слушацца и не жужжать". И таких причин можно найти море.
Только при чём здесь C++? А вот
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Hello, Дарней!
You wrote on Mon, 27 Dec 2004 08:45:29 GMT:
S>> Хоть один кроссплатформенный среди них есть?
Д> Вероятно, все остальное в твоей проге сплошь и насквозь Д> кросс-платформенное.
Не все. Но собственно рисовалка — вполне портабельная.
S>> Когда я писал конкретно тот код, актуальна была поддержка Win98. MMF S>> там работает настолько замечательно, что хоть вешайся.
Д> Любопытная информация. Откуда дровишки?
Из личного опыта. Ну и в MSDN была раньше статья Q125713 (во что сейчас
переименовали, не знаю), которая проблемы разъясняла. Все просто — гигабайт
отводится на все view memory-mapped файлов и другую совместно используемую
память (16-битные задачи и т.п). На практике — если файло больше гига, то ты
даже первые его три байта под 98 виндой не отмапишь.
S>> Еще раз, для тех кто в танке — нечего там оптимизировать.
Д> чушь. Идеальных программ в природе не бывает, как и идеальных Д> программистов.
Я не говорил — идеальная. Я говорил — по памяти ее не соптимизируешь.
S>> Я, кажется, ясно написал — protected деструктор. Если ты считаешь, что S>> от такого класса нельзя наследоваться, то о чем я тут с тобой вообще S>> говорю...
Д> Если ты не в состоянии четко и недвусмысленно описать свой случай - Д> значит, и правда говорить не о чем.
Ну и пока.
Posted via RSDN NNTP Server 1.9 delta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, adontz, Вы писали:
A>>>Потому что у этого средства помимо удешевления есть и недостатки. VD>>В основном придуманные.
A>Отсутсвие кроссплатформенности. Янус не ахти какое большое приложение, а даже если МОНО воспроизведёт весь .Net Framework 1.1 фиг он скомпилируется под линуксом. С чего бы это?
Я тебя правильно понял — если бы янус был написан на С++, то он без проблем бы под Линухом работал?
Здравствуйте, VladD2, Вы писали:
FR>>Это ни проблема языка, ни C# ни java, ни помогут в решении подобных проблем, если фирме выгоднее выпускать глючные програмы, чем доводить их до ума, то они и будут выпускатся. И вообще очень часто вместо вылета программа написанная на языке с GC неправильно работает после критической ошибки.
VD>Никому не выгодно производить глючные программы.
Ага, потому что других-то и нет.
VD>Просто еще больше не охота вкладывать денег в тотальное обезбаживаение, так как при производстве софта на С/С++ процесс этот становится двольно дорогой (особенно в рамках большой команды).
Это не потому, что на C++ сложно переписывать, а только лишь потому, что придётся заморочиться доказательством необходимости такого переписывания десятку менеджеров, которых научили, что "переписывать = suxx и mustdie". А уж тем паче, переписывать на том же языке! Театр абсурда.
VD>А язык тут как раз причем. Вместо паттернов и дорогущих систем контроля качества можно просто применять средства разработки минимизирующие ошибки и точно гарантирующие отсуствие ошибок связанных с порчей памяти.
Далась тебе эта порча памяти! Миллион раз уже объясняли, что это — не проблема. А вот то, что Janus вывалил мне 5 минут назад сообщение "feature philisophy(2) not available" со стек-трейсом, когда я не дождавшись окончания обработки сообщений после синхронизации ткнул мышой в название форума — проблема ничуть не меньшая, если не большая, чем виртуальная "порча памяти".
VD>При этом сбои становятся значительно более редки, не столь критичны (диаложик с возможностью продолжения против полного краха) и значительно проще вылавливаются.
Угу. Есессно легко ловить сбои, равномерно распределённые по всей программе. Извини. Притом, если честно, то по мне так лучше полный обвал софта, который хоть как-то заставляет менеджеров и программистов чесать задницу, чем систематически появляющийся "диаложик с возможностью продолжения", на который разработчики просто плюют. Замечательный пример — среда Java NetBeans. Не, оно не падает с GPF. Оно вообще не падает. Оно выдаёт "диаложик", а потом ты трахаешься, выясняешь: куда и что из настроек проекта делось.
VD>Наличие метаданных позволяет так же значительно упростить создание тех самых систем контроля качества.
Которые тоже выдают "диаложик", который тоже содержит возможность продолжения...
VD>Более легкий в парсинге язык позволяет автоматизированный проивзводить анализ код.
Угу, и автоматизированно нажать на Continue...
VD>Да и просто читать код становится намного проще, что резко упрощает его модификацию.
Дык, хто б спорил — нет беллетристики интересней, чем исходный код.
VD>В итоге даже опер-сорс-продукты вроде Януса, разрабатываемые очень разноскильной публикой, работают намного устойчевее чем коммерческие продукты, хотя денег и сил на их обезбаживание практически не тратится.
От эт ты в самую точку попал! Действительно — ни денег, ни сил не тратится! По Janus-у это как раз и видно.
VD>А 90% тормозов и багов вылезающих в Янусе являются проявлением используемых в нем анменеджед-контролов вроде редактора или броузера.
То ли ещё будет, когда они станут менеджед... Уж поверь, где коготок увяз, там птичке всей... GC!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
На самом деле, это всего лишь один из сюрпризов, которыми нас обеспечивает подход, когда мы вместо контроля объёма размещаемых в буфере данных делаем "резерв на все случаи жизни". А ещё — продукт воплей: "ну что ты так долго копаешься! сделай хоть как-нибудь!"
Ни больше, ни меньше.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Причём тут языки? Это технические проблемы, которые совсем не сложно решить. А вот примеров идиотских менеджерских решений, из-за которых можно смело потом идти и обвинять C++ (VB, SQL, ...) во всех смертных грехах привести можно сколько хошь.
Ну вот, от идеальных программистов мы плавно перешли к идеальным менеджерам вкупе с идеальными архитекторами, заказчиками, и прочими родственниками вакуумживущих сфероконей
Обвинять в проблемах кого-то другого можно сколько угодно, может быть, на душе от этого и станет легче. Но проблемы это никогда не решит.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК> Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?
>> Пашь, мне кажется поря познакомиться с "врагом" в лицо. Ну, что тебе стоит? Освой... язык ведь очень простой. А то развеивать твои подозрения право как-то неохота.
ПК>В смысле, "развеивать подозрения"?
Именно.
ПК> Простого ответа "да"/"нет" в данном случае вполне достаточно
Дык вопросов и подозрений слишком много.
ПК> Пока что у меня к C# интерес исключительно академический, соответственно, особенно тратить время на упражнения с ним не хочется.
Дык столько время тратится в баталях по его поводу... причем в основном идут обсуждения мифов. Глядишь 80% сналось бы само собой.
ПК> Недавно чуть было не познакомился поближе с VB.Net, решив установить DotNetNuke, но после некоторых мучений переключился на drupal, с которым пока проблем заметно меньше.
А что конкретно нужно то?
ПК>В итоге, похоже, поближе познакомлюсь с PHP
Выбор еще тот.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Все-таки, похоже, не прочитал... ПК>
Constraints-based, logic programming, functional programming, and various forms of concurrent programming are examples of good and useful styles of programming not supported by C++.
Скажи прямо что сказать то хочешь?
ЗЫ
Статью эту я прочел и ровным счетом ничего нового из нее не почерпнул.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>В том то и вся фишка, что не увеличится, а, возможно, даже уменьшится. При наличии нормального компилятора, конечно.
По разному бывает. Там где динамический полиморфизм меняется на статический бывает выигрыш. Но выигрыш этот череват ухудшением того самого дизайна. Там где шаблоны используются в качестве метапрограмм зачастую бывают как потери производительности так и в увеличение потребления памяти. В остальных же случаях вообще никакого эффекта. Так что все относительно.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
VD>>Точно! Никакого. Лики и глюки делают ламеры. А мы то круть яцоподбная! Уря товарищи!
J>Вроде из команды, а раздуваешь флейм. J>нехорошо.
Где флэйм то? Я искринне радуюсь любой глупости.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Если не секрет, не поделишься, откуда ноги у этих сказок про working set растут? Не в том смысле, что working set — это все сказки, а в том, что "дерни за SetProcessWorkingSetSize — working set уменьшится, и наступит счастье". Я уже не раз встречал подобное заблуждение, очень распостраненное на рсдн'е.
Про щастье я не знаю. Это не по адресу. Я просто продемонстрировал, что реально требуемая память значительно меньше чем то что занимается процессом в целях повышения производительности.
A>Если действительно интересует, что делает данная функция, смотрим help. Самое важное, что мы там видим, это определение понятия working set: A>
The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
A>Собственно, отсюда уже понятно, что делает SetProcessWorkingSetSize, вызванная с параметрами, как у тебя в примере. Эта функция просто отправляет наибольшее количество страниц в page file. Со всеми вытекающими, естественно. Не думаю, что ты из этого получишь какую-либо выгоду, а ущерб, как мы видим, на лицо.
Выгоду получить из этого действительно нельзя. Но этого делать и не нужно. Нужно просто понять, что до тебя пытаются донести. В данном случае я не даром после сброса ворксета создал объект. Это подняло реально используемые страницы обратоно в память и как видишь прироста мегабайтов не случилось. Так что несколько мег виртуалки занятых под процесс — это не более чем запас адрессного пространства.
A>Параметр показываемый TaskManager'ом, который тебя должен интересовать, это virtual memory.
Это почему? Мне что виртуельного места в пэйдж-файле жалого что ли? Пока памяти в системе хватает этот параметр ровным счетом ничего не значит.
A> И это будет набор memory pages, доступных для процесса (вне зависимости от их расположения в памяти или в page file). Как ты понимаешь virtual memory нельзя "уменьшить" такими трюками вроде SetWorkingSetSize. Вся память, которую, твой процесс затребовал, она вся здесь и никуда от нее не деться.
Я вот не очень понимаю каой вообще смысл рассуждать о виртуальной памяти? Меня как раз интересует та часть памяти которая реально используется процессом.
Надо же понимать, что ЖЦ принципиально занимает заранее большой кусок и в дальнейшем использует его последовательно. ОС же при этом обеспечивает распределение процессам физических страниц памяти. Проблемы с памятью или производительностью могут быть только если нехватает физической памяти и ОС приходится постоянно поднимать и сбрасывать в своп данные.
[рассуждения о кошерности VM поскипаны.]
A>Теперь нам ясно, какой параметр нам нужно стараться уменьшать. Это, во-первых, private memory. Из managed кода, это значит, что нужно меньше выделять самому и меньше использовать всякие фичи, которые любят выделять/писать в память. Еще неплохо пользоваться NGEN'ом, чтобы избавиться от необходимости JIT'а, который динамически создает код, весь попадающий в private категорию.
На практике ngen ничего не дает. Ни по памяти ни по скорости. Дает он только небольшое увеличение скорости загрузки модуля.
[рассуждения про разреженность метаданных тоже поскипаны это такие копейки, что о них и говорить не стоит]
A>Чтобы увидеть, где у тебя в процессе эти private, shared & sharable, нужно использовать vadump.
А зачем мне смотреть на дамп виртуальной памяти?
Еще раз попытаюсь объяснить. Объем знятой но не испльзуемой приложением папяти никак не влияет на производительность (по крайней мере в ОС семейства NT). Значим только тот объем физической памяти который постоянного используется процессом. Если моя программа занимает 100 мег виртуальной памяти, а использует из нее 5, то все затраты сводятся к выделению 100 мег памяти и отображению их на пэдж-файл (если это вообще не ДЛЛ). Время уходящее на заем виртуальной памяти не вилеко, но ощутимо. Время же на назначение и сброс страниц (если в них не ведется записбь) крайне мало.
Можешь произвести следующий эксперемент. Создай на анмендежед плюсах вот такой код:
int ToMByte(int bites) { return bites * 1024 * 1024; }
void main()
{
printf("1 ...");
getchar();
PBYTE mem = NULL;
mem = (PBYTE)VirtualAlloc(NULL, ToMByte(500), MEM_COMMIT, PAGE_READWRITE);
printf("2 ...");
getchar();
SetProcessWorkingSetSize(
GetCurrentProcess(), -1, -1);
printf("3 ...");
getchar();
int initSize = ToMByte(5);
for (int i = 0; i < initSize; i++)
mem[i] = i % 255;
printf("4 ...");
getchar();
}
Понажимай на энтор и погляди на реальные затраты времени и памяти.
Точно так же и дотнетный экзешник. Если есть море неиспользуемой памяти, то ворксет будет приближаться к объему закомиченой памяти. Но как только системе понадобится память, она сразу же отберет ненужные области и отдаст их другим процессам.
Реальное дотнетное приложение просто не отдает память системе рассчитывая на то, что если что та сама справится с отемом.
Хороший полигон для наблюдения за памятью является Янус. В работе он может занимать 60-80 мег оперативки, но стоит свернуть его и развернуть обратно как он нчнет занимать 12-25 мег. Причем рост памяти особо идти не будет. Но стоит попереключаться по форумам, поткрывать окна, как память снова достигнет максимума, вот только произойдет это очень не быстор. Единственный быстрый способ занять сразу много памяти — это произвести поиск по всем фомурмам. При этом, правда, дотнет будет вообще не причем, так как поиск целиком осуществляется средствами Jet-а, но MV и ворксет поднимутся до максимальных величин. И опять же банальная минимизация сбросит ворксет в копеечные величины.
К чему я все это рассказываю? Дело в том, что то что многие воспринимают за ужасную прожорливость дотнетных приложений на самом деле является самым разумным способом управления памятью в ОС семейства NT. Если памяти хватает, то операции на управление ею минимизируются. Если же ее становится недостаточно, то она переодически отнимается у дотнет-ых прцессов и отдается другим. Именно по этому дотнет больше всего поражает воображение обладателей огромных объемов памяти. Запусти то же приложение в стесненных условиях и оно начнет расходовать память намного экономнее, но эффективность от этого упадет. Все вместе это называется эффективным автоматическим управлением памятью. И не нужно пугать этим неосведомленных людей.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
VD>>>Точно! Никакого. Лики и глюки делают ламеры. А мы то круть яцоподбная! Уря товарищи! :)
J>>Вроде из команды, а раздуваешь флейм. J>>нехорошо.
VD>Где флэйм то? Я искринне радуюсь любой глупости. :)
Влад, не разыгрывай дурачка, пожалуйста, очень неприятно общаться в такой манере.
Мы с Дарнеем обсуждали конкретный баг с удалением объекта без виртуального деструктора через указатель на базовый класс: http://rsdn.ru/Forum/Message.aspx?mid=959273&only=1
Мое утверждение сводилось к тому, что такой баг посадить очень сложно.
Меморилики вообще не обсуждались.
Просто перечитай наш диалог с Дарнеем.
И когда Андрей в опровержение моих слов выкладывает ссылку на баглист с подсвеченными мемориликами, я искренне и закономерно удивляюсь, потому что мои слова вообще не касались мемориликов.
И, судя по молчанию Андрея, он с этим согласился.
Так что твою реплику про круть-не-понял-чему-подобную я квалифицирую исключительно как приглашение к флейму.
Уж уволь.
Вот когда этот топик переедет в "Священные войны" (чего мне не хотелось бы) — тогда пожалуйста, правда, в любом случае я вряд ли приму участие во флейме.
Здравствуйте, Дарней, Вы писали:
ГВ>>Причём тут языки? Это технические проблемы, которые совсем не сложно решить. А вот примеров идиотских менеджерских решений, из-за которых можно смело потом идти и обвинять C++ (VB, SQL, ...) во всех смертных грехах привести можно сколько хошь.
Д>Ну вот, от идеальных программистов мы плавно перешли к идеальным менеджерам вкупе с идеальными архитекторами, заказчиками, и прочими родственниками вакуумживущих сфероконей Д>Обвинять в проблемах кого-то другого можно сколько угодно, может быть, на душе от этого и станет легче. Но проблемы это никогда не решит.
Об том и речь.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не скажу насчёт формального багрепорта, но в Янусе нередко возникает ошибка transaction deadlock.
Ошибки бывают всегда и везде. Вопрос в критичности и массовости ошибок. Согласись, что для менеджед-кода эти показатели значительно ниже. А делдлоки... это не дедлоги, а скорее проблемы с параллельным обновлением БД из разных потоков. Короче опять Джет. С mssql-ем такого небыло бы. Просо проект не денежный и некому серьезно заняться даной проблемой, а так как не особо достает вот и живет очень давно.
ГВ>К слову сказать, 1.1.4b3.185 гораздо лучше, чем 1.1.3.
207 была самя качественная.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
A>>Отсутсвие кроссплатформенности. Янус не ахти какое большое приложение, а даже если МОНО воспроизведёт весь .Net Framework 1.1 фиг он скомпилируется под линуксом. С чего бы это? AVK>Я тебя правильно понял — если бы янус был написан на С++, то он без проблем бы под Линухом работал?
Нет не правильно. На Си++ можно написать кроссплатформенное приложение, на C# нельзя. Это не только заслуга большого количества компиляторов (кстати используя GCC можно не менять компилятор на разных платформах), но и следствите большого количества кроссплатформенных библиотек.
Те кто пишут любой софт под несколько платформ выберут Си++, поскольку как бы трудно не было писать на Си++ по сравнению с C# это всё же лучше, чем иметь .Net проект под Windows и ещё какой-то под другую ОС.
В контексте того же Януса:
Для работы с сетью используем libwww
Для отображения отображения интерфейса (не сообщений, а всего интерфейса) используем Mozilla (не ActiveX)
Не знаю как насчёт libwww, но IDE Komodo от ActiveState использует для интерфейса именно движок Mozilla. и ничего, весьма качественная IDE получилась.
Поработав с Komodo, я понял, что у VS IDE есть свои недостатки которых там нет. ИМХО среды по уровню сравнимые.
Можно было так сделать? Можно! Было бы это кроссплатформенно? Да.
Другое дело, такому плану работ помешало желание поковыряться в .Net
Здравствуйте, adontz, Вы писали: A>Те кто пишут любой софт под несколько платформ выберут Си++, поскольку как бы трудно не было писать на Си++ по сравнению с C# это всё же лучше, чем иметь .Net проект под Windows и ещё какой-то под другую ОС.
Господа, глупый наверное, но живо меня трепещущий вопрос... Что именно понимается под кроссплатформенностью?! Лично я еще не видел софта работающего под любой ОС. Все что я видел так это разные релизы для разных операционок! Но вот чтобы один и тот же релиз работал и под Win, и под Linux, и под Mac я не встречал! Так о какой кроссплатформенности вы тут общаетесь? Или я не вкуриваю во что-то?!
slegkapjan,
> Д>то есть — если использовать std::istream вместо ручного разбора данных, то это будет работать быстрее и отнимать меньше памяти?
> N.B. Вообще, потоковая система STL написана из рук вон плохо.
К STL ввод/вывод не относится. STL это только контейнеры и алгоритмы.
> Даже при чтении одного байта через istream::get() вызвается огромное количество (в том числе и виртуальных функций), что приводит к очень большой потере производительности.
De facto — да. Однако, вполне можно было сделать значительно более оптимальную реализацию, не вызывающую в процессе ввода/вывода никаких виртуальных функций в случае использования только стандартных буферов с локалью по умолчанию (что соответствует большинству случаев).
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Yachtsman, Вы писали:
Y>Здравствуйте, adontz, Вы писали: A>>Те кто пишут любой софт под несколько платформ выберут Си++, поскольку как бы трудно не было писать на Си++ по сравнению с C# это всё же лучше, чем иметь .Net проект под Windows и ещё какой-то под другую ОС.
Y>Господа, глупый наверное, но живо меня трепещущий вопрос... Что именно понимается под кроссплатформенностью?! Лично я еще не видел софта работающего под любой ОС. Все что я видел так это разные релизы для разных операционок! Но вот чтобы один и тот же релиз работал и под Win, и под Linux, и под Mac я не встречал! Так о какой кроссплатформенности вы тут общаетесь? Или я не вкуриваю во что-то?!
Честно говоря, даже внимание обращать перестал. 
