Здравствуйте, Shhady, Вы писали:
S>Кстате, смотрю вы пропагандирует C#, а как насчет производительности? Мы ж вроде в России, и дофига компов с максимум 800 мегагерцовыми пнями ( и это в офисах многих фирм ).
На этом сайте есть три статья посвязенные в том числе и этому вопросу. Если в двух словах, то нормально. На супер-новых С++-компияторах можно достичь лучших результатов, но долеко не всгда и ценой несравнимо больших трудозатрат. Целочисленная арифметика вообще мало отличима по скорости, плавающая точка малость отстает. Отстает так же работа со ссылочными типами и большими объемами памяти. За-то писать проще на порядок. И свободное время можно псвящать оптимизации алгоритмов. А это дает реальный выигрыш. Наш R# парсит C#-код как минимум не медленнее МС-ного компилятора. А если сравнивать с ихним парсером используемым для рефактоинга, то наш значительно быстрее.
800 Mz вообще не проблема. Код все же компилируется. Вот к памяти требования по выше. Но на сегодня это уже не проблема.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Silver_s, Вы писали:
S_> Тут еще есть конфликт между читателями и писателями. S_> Говорили тут вот про CWaitCursor. Если этот CWaitCursor будет самодельный класс из 4 строчек. О котором читатель не знает, а знает только что такое BeginWaitCursor. Он естействено будет материться на эту обертку когда в первый раз с ней столкнется. "..Вот в документацию лезть пришлось из-за какой-то козявки,в другие файлы лазить , скрытое поведение искать,разбираться, что за маразматик писал...итд" S_> Особенно если он с ним только один раз в коде столкнется. Ему все равно, что писателю это жизнь облегчило и в 100 местах это применено.
Сдается мне, что CWaitCursor и по названию пекрасно отражает свое предназначение. И если сравнить объем решенным им проблем (отсуствие необходимости вставлять какй-нить EndWaitCursor), то становится очевидным, что CWaitCursor резко упрощает и чтение, и отладку, и написание. Это особенно верно для С++ в котором нет finally.
S_> У писателя и читателя (которорому побыстрее хочется разобраться в небольшом обрывке чужого кода) разные цели. Иногда действительно в плоком виде структура быстрее понимается для участка кода. Но читателю можно порекомендовать запустить отладчик с первой строчки кода и прйтись насквозь через все вложеные функции скрытые поведения итд.
Если для понимания кода его нужно проходить в отладчике — то это плохой код. И пофигу что к этому приводит. Награмождение же совершенно лишних деталей приводит к этому ни чуть не меньше. Логичность и простота кода — это несомненные приемущества, но они никак не зависят от наличия или отсуствия скрытого поведения. Они зависях от лоигичности и качества проектирования. И от соблюдения некого кодекса безапастного програмирования.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вопрос прямизны рук.
Это точно.
MSS>Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.
Кому мерзость... А я на пример не хочу КАЖДЫЙ раз лезть в MSDN когда мне надо что-то сделать.
А грамотно писаные враперы интуитивно понятны.
MSS>В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.
Врапер вокруг ReadFile не имеет смысла. А вот высоко уровневая надстройка над файлами очень даже имеет.
MSS>Враппер ничего не скрывает. Как была CreateFile, так и осталась.
Этот от врапера зависит. std::ifstream тоже в конце концов в CreateFile упирается но из его интерфейса это видно?
WH>>Вот только там надо не забыть закрыть фаил... А это геморой. MSS>Правда что ли?
Если бы было не правда то всякая мерхость типа BoundsCheckr'а была бы не нужна.
MSS>Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?
При чем тут это? Я говорю об абстракции потока в который можно и читать и писать.
Поток из которого можно только читать это я понимаю, поток в который можно только писать я тоже понимаю но поток в который можно и писать и из него читать это маразм.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.
Почему у MS?
Не далее чем вчера под пингвином так указатли распечатывал.
WH>bool write_some_in_file1(char const* name)
WH>{
WH> HANDLE file=CreateFile//Когда я первый раз пытался с помощью Win32API пытался прочитать фаил я долго искал OpenFile...
WH> (name//Для того чтобы заполнить параметры функции мне пришлось лезть в MSDN.
WH> ,GENERIC_WRITE
WH> ,0
WH> ,0
WH> ,CREATE_ALWAYS
WH> ,0
WH> ,0
WH> );
WH> if(file==INVALID_HANDLE_VALUE)//За этим мне тоже пришлось лезь в MSDN ибо иногда не валидный хендел NULL и иногда INVALID_HANDLE_VALUE
WH> return false;
WH> DWORD bytes=0;
WH> bool res=WriteFile//И опять таки без MSDN не обошлось
WH> (file
WH> ,name
WH> ,strlen(name)
WH> ,&bytes
WH> ,0
WH> );
WH> CloseHandle(file);
WH> return res;
WH>}
WH>
Во блин... Я даже не понял, что этот код делает...
И чему меня только в институте учат?
Что нужно было сделать? Проверить, можно ли в файл записать?
Это если я конечно ничего не путаю насчёт возвращаемого значения printf'а.
Кто может объяснить, чем первая реализация радикально лучше второй?
Про вторую, например можно сказать, что она
1) очевидна
2) не использует посторонних относительно языка библиотек
3) кроссплатформенна
А первая чем хороша?
Это не стёб, а искренний вопрос второкурсника, который пришёл в ужас от того, как мало он знает...
A>Во блин... Я даже не понял, что этот код делает... A>И чему меня только в институте учат?
A>Что нужно было сделать? Проверить, можно ли в файл записать?
A>
A>bool try(char* path)
A>{
A> FILE* f;
A> if((f = fopen(path, "w")) == NULL)
A> return 0;
A> if(!fprintf(f, "Hello...\n"))
A> {
A> fclose(f);
A> return 0;
A> }
A> return 1;
A>}
A>
A>Это если я конечно ничего не путаю насчёт возвращаемого значения printf'а.
A>Кто может объяснить, чем первая реализация радикально лучше второй? A>Про вторую, например можно сказать, что она A>1) очевидна A>2) не использует посторонних относительно языка библиотек A>3) кроссплатформенна A>А первая чем хороша? A>Это не стёб, а искренний вопрос второкурсника, который пришёл в ужас от того, как мало он знает...
просто придирка : try — зарезервированое слово и если функция возвращает bool, надо возвращать bool
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >>технических средств.
MSS>Совершенно верно! Только почему это плохо?
MSS>Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
MSS>А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Тот случай когда аналогия хорошая но совершенно не верная. Лётчику требуется принимать жизнено важные решения часто за доли секунды... Причём скорость реакции тут куда важнее, чем глубина анализа или стратегическая продуманность решений. Ну во-первых, большинство пилотов не гении, а во вторых — талантливый пилот как раз стратегией то и занимается — для этого у него и есть мозги, и тут важно — что бы исбыток информации от приборов не занял его мозги на 110% Потому то фирма и гордилась тем, что смогла свести количество приборов к минимуму... Но! Вот пример из той же области: АВАКС Я не думаю, что фирма гордилась бы тем, что они выкинули бы половину нужных приборов из приборного отсека АВАКСА... Потому — что для него — как и для научного корабля или марсохода — важна функциональность и максимум возможностей. И приборов там сотни если не тысячи. Но тем не менее принцип минмализма действует и там. Никто не будет ставить на АВАКС 10 одинаковых приборов, если достаточно одного. Потому что дорого и энергоёмко, но никто не будет и экономить на ещё одном приборе — даже если он частично дублирует другие — но приносит реальную пользу.
По поводу C и С++. Одно из ключевых преимуществ языка — любого языка, это СОКРЫТИЕ информации — инкапсуляция поведения. Для того, что бы можно было видеть лес за деревьями. И с этой точки зрения — C++ гораздо эффективнее, чем C, так как язык позволяет управлять степенью инкапсуляции в гораздо более широких пределах: хочешь — пиши на встроеном ассемблере — хочешь — используй сложение комплексных чисел в виде близком естественному, ну а хочешь — оформяй бухгалтерские проводки в виде классов или операторов. Выбор за тобой. И, как показывает практика — на сегодня это вполне эффективный и практичный инструмент. Хотя появился C#... С другой стороны есть какие системы как Mathcad или Maple, где используется собственный язык, ориентированный на решение прикладных задач этих систем. Есть так же CAD или бухгалтерские системы — где есть свои встроеные языки, гораздо более подходящие для работы с этими системами, чем C или C++.
Здравствуйте, VladD2, Вы писали:
VD>Ну, zero overhead даже на ассемблере не бывает.
zero overhead это по сравнению с асмом.
VD>Реально речь идет о процентах. Как я уже не раз говорил проигрыш в два раза легко компенсируется высобожденым временем которое можно потратить на оптимизацию алгоритмов. А те в свою очередь дают куда блоший чем двухкратный выигрыш.
Ты о чем? У C# на алгоритмических задачах как минимум нет преймуществ перед С++.
VD>Другое дело, что есть драйверы и т.п. Вот их конечно придется делать на С/С++. Как видишь, даже можно поспорить на чем из них луше.
Проблема в том что это "и т.п." имеет очень не маленкий обьем... На пример у меня в городе в основном этот самый "и т.п." И туда назрел новый язык. С просто не выдерживает ни какой критики, да и в С++ хватает проблем. Хотя если писать на С++ грамотно то проблемы не возникают. VD>Задачи же более менее прикладные легко преводить на дотнет. Если что проблемы вставить пару строк на анменеджед-С++ особого труда не составит.
Не спорю.
VD>Ну, я бы все же лучш дополнил существующий.
Дополнять существующий очень сложно. Да и проблем в нем хватает... Взять хотябы A Little Detail in Overload 60
Про Сишные маразмы я вобще молчу.
VD>В смысле как это можно было бы интегрировать в С++? Или вообще?
Что либо интегрировать в С++ врятли получится. Хотелось бы вобще.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>Я не буду предираться.
Там еще смайлик был . В любом случае я не хотел сказать ничего плохого.
AJD>>А почему он должен там быть? S>Так думают и программисты в ms.
S>MSDN по поводу WM_PAINT ( это относитьяс к OnPaint ) S>
S>Typically, an application draws in a window in response to a WM_PAINT message.
S>Понятно, что тупикали, ну если сами программисты ms нифига не тупикали обрабатывают отрисовку черт знает где ( сорсов же контроллов нет ), то как это расценивать? Если это документированная ( хорошо, могу согласиться, они же сами пишут "тупикали" ) и ожидаемая реализация отрисовки, то я пас.
Хорошо, а если мне надо вывести контрол на печать или еще куда(в метафайл)? WM_PAINT в данной ситуации не прийдет просто, хотя рисование тоже самое. Поэтому вполне логично, вынеси это все в отдельную функцию на вход которой передается настроенный соответсвенно девайс контекст. И этой функции глубоко начхать в какой девайс контекст рисовать: в экранный или принтерный. Имхо как раз в этой ситуации все правильно.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ilya_ny, Вы писали:
_>>я не понял что ты имеешь в виду — человек писал, что в 2001 C# не было, а я писал, что был.
VD>Человек — это был я. Так вот официально С# вышел в 2002 году. Его бетатестирование было закртытым и сотрудник МС распространяться про него да еще так вольготно словно о нем все давно знают в 2001 попросту не мог. Его а) никто бы не понял, б) выгнали бы с работы.
microsoft в 2000, 2001 гг рассылал диски с Visual Studio.NET RC1, RC2...
я даже помню, что они были белого цвета
и при чем тут закрытое тестирование вообще
VD>>>Ну, прям прозводсво каое-то. Хорошо что ты не программировал на супер продукте под названием COM+: VD>>>http://www.microsoft.com/msj/1197/complus.aspx VD>>>http://www.microsoft.com/msj/1297/complus2/complus2.aspx VD>>>
_>>я программировал.. а тут в чем подвох ?
VD>Тем что это и есть дотнет. И программировать на нем ты мог, только если ты работал в то время в команде его разработки.
COM+ — это то, что было еше под Windows NT — только устанавливалось отдельно — называлось MTS
может внутрене .NET и реализован с использованием COM+ технологии, но так это совсем разные вещи
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Shhady, Вы писали:
S>>Я лично ждал ответа, а не флейма. И что вы хотели этим сказать?
AVK>То что не стоит выдавать это за сокровенное знание и жуткий профессионализм.
Я что-то не понимаю, если вы неправы, то что, сложно это признать? А не ходить до окола.
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, AndrewJD, Вы писали:
AJD>Хорошо, а если мне надо вывести контрол на печать или еще куда(в метафайл)? WM_PAINT в данной ситуации не прийдет просто, хотя рисование тоже самое. Поэтому вполне логично, вынеси это все в отдельную функцию на вход которой передается настроенный соответсвенно девайс контекст. И этой функции глубоко начхать в какой девайс контекст рисовать: в экранный или принтерный. Имхо как раз в этой ситуации все правильно.
Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar? Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?
Ну ладно, это чисто офф
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, SWW, Вы писали:
MSS>>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором.
SWW>А я иногда создаю переменную типа CWaitCursor и нигде ее не использую. Похоже, меня тоже скоро уволят.
MSS
1. можно херить простые переменные, которые нигде (int, char, double) не используются, а не объекты — что твой же пример и доказывает
2. что же это за программист, который так херит ничтоже сумняшеся?? может это его надо увольнять ?
3. может если переменная или класс имеет осмысленное имя — ExchangeConnect, например, то ее просто так и не захерят ?
Здравствуйте, Maxim S. Shatskih, Вы писали:
S_>> Хотя тут скрытого поведения нету. Вот поэтому крупный софт и глючный на основе >>низкоуровневых технологий (без скрытого поведения), и лезут через инет на комп >>всякие черви через всякие щели.
MSS>То-то одна из самых глючных софтин на настоящий момент — написанный на Си++ MSIE.
MSS>То-то ядра Windows и юниксов работают хорошо, то-то компиляторы работают хорошо... все на Си
Максим, ну не надо передёргивать. Я думаю, все прекрасно знают, что качество продукта определяется качеством программистов, его писавших. Проза жизни в том, что даже Майкрософт не в состоянии укомплектовать свой штат программистами хотя бы среднего уровня.
, скрытое поведение искать,разбираться, что за маразматик писал...итд"
. В любом случае я не хотел сказать ничего плохого.
Похоже, меня тоже скоро уволят.
