Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>По обмолвкам на форуме одного из ключевых людей, которые портировали NT на PPC, получается, что NT на PPC стала коммерчески нафиг никому не нужна тогда, когда Стив Джобс удушил юридически рынок клонов Макинтошей. В конце 90х.
И какая связть с Эплом? Просто NT на экзотике в принципе не целесообразно. МС нужны миллиарды, а в на экзотике можно заработать только имя.
MSS>Теперь общие соображения. Пентиум и Атлон — едва ли не быстрее всех этих Спарков и МИПСов. По целочисленной арифметике быстрее. Причина понятна — у Интела и АМД лучшая силиконовая технология, лучше, чем у Сана и Тексас Инструментс, которые Спарки делают на пару. Лучше, чем у MIPS. И так далее.
В те времена это было не так. Алфы рвали по частотам всех. Вот только под NT они были бесполезным железом. Драйверы левые. ОП нет. Спрос нулевой. К примеру, авишник шел на хваленой альфе в три раза хуже чем на пне. А инженерные рассчеты можно было делать и на других ОС.
MSS>Дальше. Сам процессор типа Спарка может стоит дешевле, чем Пентиум. Но он у нас собственность конкретной компании, которая заодно собирает на нем машины и к ним дает ОС. На этот рынок воткнуть свою ОС очень сложно. Для этого та родная ОС должна быть совсем отстой.
MSS>Именно потому порт НТ просто принесет совсем немного денег Майкрософту. Вот и все. Итаниум — другой разговор. Все еще есть шансы, что это будущее массовых десктопов. Такую штуку Майкрософт не упустит.
А я думаю, что NT на экзатике полностью убыточен. МС наворотила в NT много фич трудных к переносу. Все эти PNP и самовостановления привязывают ОС к железу. До 2000-ных NT переносилась на другую машину простым копированием. Теперь вероятность того что ОС заработает при смене матери стремится к нулю. Это не может не влиять на переносимость. Вернее на ее стоимость. Так что откат от продаж должен быть весомым. И разные Альфи, Мипсы и т.п. это просто не обеспечивают.
MSS>Более того. Есть сплетня, что DEC потребовала от Майкрософта разработать порт Альфы, угрожая судом насчет того, что Катлер унес некоторые конфиденциальные сведения о VMS, на опыте которой была основана архитектура НТ. Якобы без этой угрозы и на Альфу НТ бы не портировал никто.
Видимо вынуждали Компак их купить. Честно говоря идея с NT на альфе была коммерчески дохолой. Скорее это был эксперемент доказывающий возможности переносимости. У МС же тогда это был натуральный комплекс неполноценности.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ilya_ny, Вы писали:
_>смешно.. _>я лично программировал в начале 2001 на C# (Beta 2)
Значит должен знать, что такое DNA и какие ограничения на треп оно распростроняет.
Я программировал еще на пре бете и на бэте 1. И именно по этому могу скзать, что вероятность появления этих слов в 2001 стремится к нулю.
_>более того, я использовал С# код, созданный другим разработчиком в 2000
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>К чему? Мне нужно напечатать значение типа size_t. Как?
VD>Раз формат %u значит к unsigneg int.
Здравствуйте, VladD2, Вы писали:
MSS>>Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному
VD>Дык то не романтик, то фанат.
А вот этого — не надо!
Нам, зверькам, фанатизм не к лицу — рАмантики мы
И ваще — еще раз на меня таким словом заругаешься — за нос укушу.
VD>Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...
Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе.
(Предвидя толпу любителей фразы "мальчик, с такими понятиями денег не заработать", предупреждаю — зарабатываю. на хлеб с икрой — хватает.)
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Цена баги в человеко-часах. Любой UI по этому параметру — сразу относится к простому программированию. Сразу. Потому как любой баг в UI находится мгновенно. Потому как у UI крайне редко бывают interop issues.
Расскажи — это тем орлам из МС которые Ворд пишут (я так понимаю на С). А то уже так задолбало, что за последние 10 лет они не смогли выпустить ни одной версии ворда без серьезнейших багов.
За одно расскажи команде дотнета и КОМ-а о противоречии метаинформации основам ООП.
Приколько так же будет расскзать группе компиляторов о вреде модификаторов доступа.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shhady, Вы писали:
S>Я конечно не использую dynamic_cast, темплейтов и эксепшенов, и очень доволен, и использовать не хочеться.
И очень зря. Чертовски полезные вещи. Хотя исключения сделаны (особенно в компиляторах МС) не очень толково. Но уж шаблоны не использовать работая с КОМ-ом — это верх мазохизма. Все же ATL непропьеш.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Сами по себе обертки уже есть детали. Те самые. MSS>А если баг в обертке где? Ой млиииин...
Если баг в обертке, то рано или поздно он будет обнаружен и устранен. А вот если баги (а они будут такими же что и в обертке) разбросаны по коду, то это уже называется "приплыли".
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ну если совсем практика показывает, что постоянно хэндлы текут у данной конкретной команды — сделай так:
MSS>class CHandle MSS>{ MSS> HANDLE m_Handle; MSS> CHandle(HANDLE h){ m_Handle = h; } MSS> ~CHandle(){ ::CloseHandle(m_Handle); } MSS> operator HANDLE(){ return m_Handle; } MSS>};
Т.е. ты не совсем против враперов? Или у тебя свои понития об этом деле? Понятно.
Вот только как это соотвествует утверждению, что на С программа надежнее и недолжно быть невидимых эффектов?
MSS>- и юзай как хочешь. Полная прозрачность, как у смартпойнтера. Единственная разница — в месте объявления handle и вызове CreateFile.
С Апи-шными функциями есть одна проблема. Им в параметры можно подсунуть все что угодно. Они ведь в столь любимом тобой С-стиле объявлюятся (для совместимости). А С язык совсем ничего не знающий о типобезопасности. Сделать простую обертку над CreateFile заменив безликие константы на энумы и скрыв незначимые для прекладного программиста параметры ты повысишь надежность кода.
Вот только С++ сдесь тоже фиговый помошник. Уж больно вольно он относится к приведению типов. В шарпе, например, привести неявно энум к целому или наоборот невозможно. И с обертками особых проблем нет. Например для чтения текстовой информации изумительно подхтдит врапер вроде StreamReader. Зачастую код ограничивается вот таким вариантом:
Напиши аналогичный код на Апи без враперов и предложим сравнить другим какой код более понятен и читабелен.
В следующем фрэймворке вообще будет отдельная функция позволяющая считать содержимое файла без явного его открытия.
MSS>Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.
Есть и дугая теория. Враперы инкапсулируют логику и предоставляют более высокоуровневую абстракцию. Это позволят упростить написание, чтрение и поддержку кода.
MSS>В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.
Ну, я знаю не мало контор которые не взяли бы человека на работу в следствии высказывания им одного из высказанных тобой утверждения. Что с того?
Ты постоянно себе противоречишь. С одной стороны ты вроде ратуешь за инкапсуляцию, полиморфизм. С другой низводишь базовые концепции ОО. Причем ради чего? Ради упрощения. Но каое же упрощение если вместо простой, лаконичной и понятной строчки унжно написать 10 перенапичканные ненужными деталями?
MSS>>>Смартпойнтеры — один разговор. Обертки — бредятина полная. Забивание мозгов лишней >>информацией. WH>>В чем разница? И те и другие созданы для того чтобы скрывать детали.
MSS>Враппер ничего не скрывает. Как была CreateFile, так и осталась.
Это в CHandle то? Он же нарушает главное (по-твоему) правило — делает невидимые действия. Ты же вроде обвинял в этом приведение типов и пергрузку операторов.
WH>>Вот только там надо не забыть закрыть фаил... А это геморой.
MSS>Правда что ли?
Если бы было не правдой, то на свете небыло бы столько глючных и текущих программ.
WH>>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без >>произвольного доступа что есть маразм.
MSS>Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?
Вот тут согласен. Потоки разные важны, потоки разные важны.
>>виртуальный деструктор — это святое. WH>>Это догмы.
MSS>И? Ты же сам тут огласил другую догму, а именно "врапперы обязательны".
Опять согласен. Вот только какая разница от чего будет глючить приложение, от неверно вызванного деструктора, или от незакрытого файла?
MSS>Невиртуальный деструктор приводит к отвратительным гиморам, которые очень сложно потом ловить. Есть рекомендация автора языка — везде, где есть вообще VMT, делать виртуальный деструктор. Разумная и обоснованная.
Этим авторам бы пошее дать. И объяснить, что если это так важно, то нужно было вводть не разрешительную, а запретильную политику. Ну, чтобы программист сам и явно говорил "не нужен мне ваш виртуальный деструктор". Тогда таких багов было бы минимум.
MSS>Какие детали прячет обертка вокруг WriteFile?
Ну, не тебе рассказывать сколько у нее параметров насколько неприятно их путать. Это тебе может ясно что такое разные OVERLAPPED и т.п. А прикладнику все это до лампочки ему нужно файл на диск сбросить. К тому же WriteFile довольно простой метод. А вон с CreateFile будет посложнее. К тому же не каждый знает что для открытия вайлва нужно вызывать именно ее, а не OpenFile. Ну, а если учесть, что человек не помешанный на битах читает из файла структурированные данные, то понятно, что обертка может очень сильно облегчить ему жизнь предоставив методы форматированного чтения и записи (а то и обеспечить контроль).
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>А вот этого — не надо! ЗХ>Нам, зверькам, фанатизм не к лицу — рАмантики мы ЗХ>И ваще — еще раз на меня таким словом заругаешься — за нос укушу.
Да, я так шутя.
VD>>Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...
ЗХ>Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
Дык ты видел пиониста получающего удовольствие от того, что его пальцы запутываются в клавишах и прилипают к ним? Вот так же язык можт позволить забыть о деталях и творить. Думать об идях, а не о битах, операторах и другой фигне.
ЗХ>Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе.
Лучше идти в начальство.
ЗХ>(Предвидя толпу любителей фразы "мальчик, с такими понятиями денег не заработать", предупреждаю — зарабатываю. на хлеб с икрой — хватает.)
Да, кто же проитв то? Мериться членами на счет зарабатываемого не буду. Да и не в этом счастье. Я пишу код не за деньги и получаю от этого удовольствие. Вот это я и называю рамантикой.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ЗХ>>Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
VD>Дык ты видел пиониста получающего удовольствие от того, что его пальцы запутываются в клавишах и прилипают к ним? Вот так же язык можт позволить забыть о деталях и творить. Думать об идях, а не о битах, операторах и другой фигне.
А вот не надо меня учить, от чего удовольствие получать!
Для меня кайф не только в том, чтоб сообразить крутую архитектуру, по-быстрому реализовать и посмотреть, что получилось.
Но и в создании хелпер-класса на 10 строк, над которым я бился 4 дня. Чес-слово!
Равно как и когда я пишу сказку — мне нравится чувствовать каждое слово, чувствовать, что я нашел единственный вариант из 18000 возможных. Просто вот такой подход у меня к написанию программ.
ЗХ>>Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе. VD>Лучше идти в начальство.
Фигня это, извиняюсь. Кому, может, и лучше.
А нас и тут неплохо кормят.
VD>Вот это я и называю рамантикой.
Каждому свое, и спорить, в общем-то, не о чем.
В "истории одного байта" тоже полно романтики. На самом низком уровне
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>Раз формат %u значит к unsigneg int.
Ш>>С возможной потерей значения?
VD>Ну, тут оно как. В большинстве случаев это невероятно. Если вероятность все же есть, то преобразуй к заведому большому типу и выводи его.
Какому? Это зависит от системы. Нет в С способа использовать printf системно-независимым способом. Сейчас Майкрософт вводит Win64. В этой системе size_t -- 64 разрядный. Он будет больше long.
Т.е. его вообще невозможно распечатать используя стандартные коды форматирования. Соответсвенно, весь C-шный код, написанный для Win32, надо тюнить под новую систему просто ручками переписывая все строки форматов. И при этом новый код будет Win64-only. Абзац. И кто-то после этого тут ещё заливает насчет сложностей с переносимостью и сопровождением C++ кода. С порождает куда большие проблемы.
VD>Ну, а то что в С/С++ функции с переменным количеством параметром полное дермо никто и не спорит.
Если ты имеешь ввиду ..., то да. Единственное полезное использование -- только в мета-программировании.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Претензии к ОО в основном идут к наследованию, которое действительно делает из простых задач сложные. Уж лучше дублирование кода, чем отстойно спроектированное дерево наследования. А спроектировать его правильно — простите, но мало кто может. Тут нужен действительно талант, а не средне-рыночные навыки умника за 1200 долларей.
Вот небольшой пример кода в чисто сишном стиле, хоть там и используются интерфейсы. Но это особой разницы не делает.
Всё в твоем любимом стиле — никаких ссылок, никаких исключений, никаких деструкторов.
#include <windows.h>
#include <winbase.h>
#include <initguid.h>
#include <ole2.h>
#include <mstask.h>
#include <msterr.h>
#include <wchar.h>
int main(int argc, char **argv)
{
HRESULT hr = S_OK;
ITaskScheduler *pITS;
///////////////////////////////////////////////////////////////////
// Call CoInitialize to initialize the COM library and then
// CoCreateInstance to get the Task Scheduler object.
///////////////////////////////////////////////////////////////////
hr = CoInitialize(NULL);
if (SUCCEEDED(hr))
{
hr = CoCreateInstance(CLSID_CTaskScheduler,
NULL,
CLSCTX_INPROC_SERVER,
IID_ITaskScheduler,
(void **) &pITS);
if (FAILED(hr))
{
CoUninitialize();
return 1;
}
}
else
{
return 1;
}
///////////////////////////////////////////////////////////////////
// Call ITaskScheduler::Activate to get the Task object.
///////////////////////////////////////////////////////////////////
ITask *pITask;
LPCWSTR lpcwszTaskName;
lpcwszTaskName = L"Test Task";
hr = pITS->Activate(lpcwszTaskName,
IID_ITask,
(IUnknown**) &pITask);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskScheduler::Activate: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
pITS->Release();
///////////////////////////////////////////////////////////////////
// Call ITask::CreateTrigger to create new trigger.
///////////////////////////////////////////////////////////////////
ITaskTrigger *pITaskTrigger;
WORD piNewTrigger;
hr = pITask->CreateTrigger(&piNewTrigger,
&pITaskTrigger);
if (FAILED(hr))
{
wprintf(L"Failed calling ITask::CreatTrigger: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
//////////////////////////////////////////////////////
// Define TASK_TRIGGER structure. Note that wBeginDay,
// wBeginMonth, and wBeginYear must be set to a valid
// day, month, and year respectively.
//////////////////////////////////////////////////////
TASK_TRIGGER pTrigger;
ZeroMemory(&pTrigger, sizeof (TASK_TRIGGER));
// Add code to set trigger structure?
pTrigger.wBeginDay =1; // Required
pTrigger.wBeginMonth =1; // Required
pTrigger.wBeginYear =1999; // Required
pTrigger.cbTriggerSize = sizeof (TASK_TRIGGER);
pTrigger.wStartHour = 13;
pTrigger.TriggerType = TASK_TIME_TRIGGER_DAILY;
pTrigger.Type.Daily.DaysInterval = 1;
///////////////////////////////////////////////////////////////////
// Call ITaskTrigger::SetTrigger to set trigger criteria.
///////////////////////////////////////////////////////////////////
hr = pITaskTrigger->SetTrigger (&pTrigger);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskTrigger::SetTrigger: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
///////////////////////////////////////////////////////////////////
// Call IPersistFile::Save to save trigger to disk.
///////////////////////////////////////////////////////////////////
IPersistFile *pIPersistFile;
hr = pITask->QueryInterface(IID_IPersistFile,
(void **)&pIPersistFile);
hr = pIPersistFile->Save(NULL,
TRUE);
wprintf(L"The trigger was created and IPersistFile::Save was \n");
wprintf(L"called to save the new trigger to disk.\n");
///////////////////////////////////////////////////////////////////
// Release resources.
///////////////////////////////////////////////////////////////////
pITask->Release();
pITaskTrigger->Release();
pIPersistFile->Release();
CoUninitialize();
return 0;
}
Ну как, хорошо? Пока работает — замечательно.
А потом кому-то понадобится этот код модифицировать, и он влепит посреди функции return и забудет позвать какой-нибудь из Release(), или CoUninitialize()
Или создаст новый объект на куче и забудет поставить delete в каждую из дестяка точек, где может происходить выход из функции.
Чудно будет, правда?
Я уж не говорю о том, что в этой функции полезного кода процентов 10 наверно будет, а всё остальное — это просто дублирование.
Хотя кажется мне, зря я это всё пишу. Автор темы — или фанатик, или провокатор. Любые аргументы он просто не поймет.
А теперь можно смело ставить мне минусы
VD>Не, давным давно МС выпустил слух о том что в его недрах делается ОС нового поколения. И кодовое имя проекта Cairo. Это действительно было до ДКОМ-а. Подробностей я уже не помнь, но среди плано были ОО-файловая систем и т.п. В общем в Лонгхорн — жалкая породия. Возмжно ДКОМ как раз под это дело и делали. Только планы били несколько глобальными. В общем, сделай поиск по словам "Cairo ОС" и погляди на результаты...
Знаю я это. Все, что на деле осталось от этого прожекта — это DCOM.
Отладчик от WinCEшного Platform Builder постоянно показывает полные пути к файлам исходников. Из них сразу делается 2 вывода а) сама ОС называлась mckendrick и б) DCOM назывался cairo.
MSS>>Обычный пиар. Было это эдак в 94-95. Тогда была модна идея ОО ОС, которая у всех с >треском провалилась — и IBM Workplace OS, и Novell AppWare. VD>Ну, Next был куда раньше, и ОО там было немало.
Я щупал руками NextStep в 94ом году.
В самом низу — Mach microkernel. Поверх него — BSD-compatible ядро. Структура директорий почти BSDшная, и совсем не System V.
Поверх этого — графический движок Display Postscript.
А вот уже поверх него начиналась объектность в виде классов UI. Как язык рекомендовался Objective C, и была среда разработки под него, до жути похожая на Дельфи, но старше Дельфей на несколько лет, и потому в те времена поражавшая воображение.
Визуально это предшественник AfterStep и WindowMaker из современных юниксов.
VD>Скорее всего DCOM был частью проекта с общим названием каиро.
Да, наверное, так и было. Проект был зело распиаренный.
MSS>>По обмолвкам на форуме одного из ключевых людей, которые портировали NT на PPC, >получается, что NT на PPC стала коммерчески нафиг никому не нужна тогда, когда Стив >Джобс удушил юридически рынок клонов Макинтошей. В конце 90х. VD>И какая связть с Эплом?
Я так понимаю — НТ планировали как альтернативу МакОСу для клонов Эпплов, чтобы клонмейкеры стали совсем независимы от Эппла.
МакОС тех времен был совсем убог по нижним уровням ОС.
VD>В те времена это было не так. Алфы рвали по частотам всех. Вот только под NT они были >бесполезным железом. Драйверы левые.
Хуже. НТ не на любой Альфе шла, а только на специальном ПАЛкоде, который делал из Альфы 32битный процессор.
VD>А я думаю, что NT на экзатике полностью убыточен. МС наворотила в NT много фич >трудных к переносу. Все эти PNP и самовостановления привязывают ОС к железу.
Во-первых, PnP тогда не было, он в НТ появился только в w2k.
Во-вторых, PnP наоборот развязывает ОС от железа скорее. Модульность увеличилась. Например, до-PnPшный драйвер должен был знать о том, что бывает на свете ISA, а бывает PCI. Если, конечно, его чип бывает для той и для другой шины. А PnPшному драйверу в этом вопросе все пофиг. Дали ему CM_RESOURCE_LIST, где описаны адреса железки — и все.
>До 2000-ных NT переносилась на другую машину простым копированием. Теперь вероятность >того что ОС заработает при смене матери стремится к нулю.
Из-за ИДЕ в основном. Другой ИДЕ чип, не соответствующий драйверу.
Еще из-за ACPI и багливых таблиц в биосах — во времена пентиума-3 была не редкость.
>У МС же тогда это был натуральный комплекс неполноценности.
Факт.
Я еще когда молодой был, в 95ом году, слышал от своего тогдашего шефа (главный менеджер в одной фирме, которая Microsoft Solution Provider) — "Microsoft есть убогая персоналочная компания, у них один Ворд и Эксел, и ихний Бэкофис из пальца высосан — куда они лезут-то на рынок тяжелых систем, они там не понимают ничего..."
Ш>Т.е. его вообще невозможно распечатать используя стандартные коды форматирования.
Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.
VD>>Ну, а то что в С/С++ функции с переменным количеством параметром полное дермо никто >и не спорит.
Дерьмо в основном тем, что туда класс не передашь.
Честно говоря идея с NT на альфе была коммерчески дохолой. Скорее это был эксперемент доказывающий возможности переносимости. У МС же тогда это был натуральный комплекс неполноценности.
