Здравствуйте, Serginio1, Вы писали:

V>>А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.

S> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net

Ага, но при этом легко получить вариант a la Navision.

Hello, Maxim!
You wrote on Fri, 11 Jun 2004 11:39:42 GMT:

MSS>>> Творческое пользование темплейтами также сможет доставить потомкам
MSS>>> немало приятных минут.
S>> Бывает. Но если нет шаблонов, то вместо них на помощь приходят
S>> макросы... А это вообще жопа.

MSS> Темплейты как раз хорошая фича. Одна из лучших в Си++.

Хорошая. Но в неумелых руках такая же опасная, как и объявление функции без
аргументов в C. И виртуальные функции — тоже хорошая фича, и тоже опасная,
хотя и не такая опасная, как шаблоны. И что самое главное, обе этих фичи
позволяют избежать дулирования кода, что радикально облегчает сопровождение
программ. Как, впрочем, и макросы с указателями на функции в С.

MSS>>> Вышли из блока -- значит, вышли, и нечего кроме.
S>> И забыли закрыть половину хэндлов....

MSS> Сразу видно. Локально видно. Легко править.

Править, может, и легко, а вот дописывать новую функциональность — трудно.
Кроме того, налицо подмена понятий — цель не в том, чтобы ошибки исправлять
легче было, а в том, чтобы ошибок меньше было, при тех же трудозатратах.

MSS>>> Очевидно, что чем проще язык программирования, тем трудней сделать
MSS>>> на нем семантическую ошибку.
S>> Если б это было правдой, все бы до сих пор писали на ассемблере.

MSS> Ассемблер сложнее Си.

Смотря какой. Хотя даже для x86 — не сложнее С, примерно одна фигня. А вот
писать на нем — сложнее чем на С. А на С++ писать проще, если квалификация
позволяет. Хотя язык сложнее.

MSS> Си — оптимальный язык для близкого к машине программирования.
MSS> Позволяет все, что и ассемблер (ай, ну да, кроме CPUID — и при
MSS> этом не содержит скрытой семантики.

Скрытой семантики нет и в С++ — она только для закоренелых сишников скрытая.

MSS> Прятать мелочи — глупо.

Нет, прятать их — целесообразно. Что, например, делает функция memcpy, как
не прячет мелочи?

MSS> Баги будут именно в них.

Баги будут в них, если их выставлять на показ, т.е. каждый раз переписывать
заново.

MSS> The devil is in the details.
Во-во.

MSS> Потому имеет смысл выставить эти детали бесстыдно наружу, чтобы
MSS> быстрее баг увидеть, если он там есть.

Чтоб за деревьями леса не увидеть... Попробуй найди баг в функции из 1000
строк, из которых 2/3 — обработка ошибок и очистка ресурсов. Достаточно 1
раз нерешливо написанную на С программу переписать на С++, чтобы в этом
убедиться.

А насчет новичков — это сейчас их в С не осталось, а посмотреть на
ширпотреб, написанный в конце 80х-начале 90х годов "среднестатистическим
программистом". На С++ мне такой кошмар ни разу не попадался.

With best regards, Sergey.

S>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net

V>Ага, но при этом легко получить вариант a la Navision.

Хехе. А ведь РСДН-то Навизионцы читают )

Здравствуйте, Зверёк Харьковский!

Я аплодировал.
Спасибо!

Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>Типичное возражение, и совершенно неверное.

Ну конечно...

MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.

Да, только у человека с высокой квалификацией этот объем повыше чем к примеру у алканафта-слесаря. Тем они и отличаются в первую очередь.

MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.

Ага А необходимость листать 500 функций — это огромный плюс?

MSS>Использование оператора сдвига для печати — в минус.

Добавляй "Я думаю"

MSS>Это вопросы азов эргономики.

А че там эргономика говорит нам про оператор сдвига?

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.

MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.

Приживается.

Мы используем C++ и STL для разработки модулей ядра под Linux и Windows NT.
В результате проект, который местный защитник plain C писал год, был закончен за пол-года.
А по скорости даже выиграл у сишного прототипа.

Страшилки про использование C++ в ядре рассказывать не надо — мы их знаем.

Мне кажется, что история как всегда повторяется.
Nдцать лет назад тоже гремели баталии на тему "asm vc C".
Любители всё держать под контролем так же рассказывали про кривой язык C. Соглашались, что они программируют медленно, но зато генерируют намного более оптимальный и предсказуемый код, чем компилятор. Сравнения кода приводили. И так же боролись с попытками писать VXD на C.

Время всех рассудило.

Здравствуйте, Crab, Вы писали:

S>>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net

V>>Ага, но при этом легко получить вариант a la Navision.

C>Хехе. А ведь РСДН-то Навизионцы читают )

Ну и что? Думаете, они сами редко делают вот так: [ ]?

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Crab, Вы писали:

S>>>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net

V>>>Ага, но при этом легко получить вариант a la Navision.

C>>Хехе. А ведь РСДН-то Навизионцы читают )

V>Ну и что? Думаете, они сами редко делают вот так: [ ]?



Я пишу доработки под Navision Axapta. Так никогда не делал.
Мне кажется, там все сделано очень хорошо. А что Вам не нравится?

Здравствуйте, Maxim S. Shatskih, Вы писали:

Здается мне, что это "эссе" написано не сотрудником МС, а кем-то кому охота пофлэймить.

Грабли — это конечно не хорошо. Но голопом на С — это просто бред сивой кобыли.

И текст этот у тебя в 91 быть не мог. Тогда ни Шарпа, ни Явы еще в помине небыло. Да и С++ то был на С++ не похож. Шаблонов еще небыло, к примеру. А в тексте про это упоминается.

ЗЫ

Ты этот текст не сам часом написал?

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.

Ага. А если лепить в столбик в стиле С, то внимание будет на месте?

Общая идея повышения качества ПО — это повышение уровня разрабтки/языка и упрощение изложения/восприятия кода. Если у тебя будет 100 мег плоского кода, то понять в нем ты ничего не сможешь даже если он будет написан в солбик и с минимумом уловных переходов.

Здравствуйте, Exhumer, Вы писали:

E>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.

Можно узнать чем ООП может помешать драйверам?

Здравствуйте, VladD2, Вы писали:

VD>И текст этот у тебя в 91 быть не мог.

Может, здесь просто ачипятка и имеется в виду 2001 год?

Здравствуйте, Chris, Вы писали:

V>>Ну и что? Думаете, они сами редко делают вот так: [ ]?

C>Я пишу доработки под Navision Axapta. Так никогда не делал.
C>Мне кажется, там все сделано очень хорошо. А что Вам не нравится?

Ахарта, конечно, покрасивше будет. Насчёт "очень хорошо" — спорить не буду. Скажу только, что мне она не очень понравилась по совокупности параметров, хотя некоторые заложенные в неё идеи просто восхитительны. Предлагается закруглить перемывание косточек MBS.

Тема-то была про другое. Navision просто под руку попался как иллюстрация неоднозначной зависимости скорости выполнения программ от скорострельности интерпретатора.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
Не понял аргуманта.

MSS>Прекрасный пример! Многомиллиардная корпорация!
А теперь посмотри на амереканцев... жрут в МакДональдсе и выглядят как... ну вы поняли... Короче я считаю что МакДональдс гораздо опаснее чем БенЛаден и компания... В отличии от террористов МакДональдс убивает милионами причем с особой жестокостью и цинизмом.

Здравствуйте, Maxim S. Shatskih, Вы писали:

S>>И забыли закрыть половину хэндлов....
MSS>Сразу видно. Локально видно. Легко править.
А в моих программах ошибок такого класса вобще нет и быть не может. Ибо взятся им не откуда... любимые тобой деструкторы все хендлы закрывают обожаемым тобой скрытным образом...

The devil is in the details.

Великая фраза... А иметь дело с дьяволом...
А вывод из этого: Не имей дело с деталями те детали должны быть спрятаны.

Взят хотябы бональную работу с файлами...
Си вариант с деталями.(а все ли я учел? очень давно с WinAPI на прямую не работал )

bool write_some_in_file1(char const* name)
{
    HANDLE file=CreateFile//Когда я первый раз пытался с помощью Win32API пытался прочитать фаил я долго искал OpenFile...
        (name//Для того чтобы заполнить параметры функции мне пришлось лезть в MSDN.
        ,GENERIC_WRITE
        ,0
        ,0
        ,CREATE_ALWAYS
        ,0
        ,0
        );
    if(file==INVALID_HANDLE_VALUE)//За этим мне тоже пришлось лезь в MSDN ибо иногда не валидный хендел NULL и иногда INVALID_HANDLE_VALUE
        return false;
    DWORD bytes=0;
    bool res=WriteFile//И опять таки без MSDN не обошлось
        (file
        ,name
        ,strlen(name)
        ,&bytes
        ,0
        );
    CloseHandle(file);
    return res;
}

Имея обертку которая просто делегирует вызовы в Qin32API мы уже можем писать так

bool write_some_in_file2(char const* name)
{
    CWin32API_File file
        (name
        ,GENERIC_WRITE
        ,0
        ,0
        ,CREATE_ALWAYS
        ,0
        ,0
        );
    if(!file.is_valid())//избавились от магической константы INVALID_HANDLE_VALUE
        return false;
    DWORD bytes=0;
    //избавились от необходимости создавать промежуточную переменную для запоминания результата WriteFile
    return file.write
        (name
        ,strlen(name)
        ,&bytes
        ,0
        );
    //И на конец избавились от необходимости закрывать хендл руками
};
//Хотя за параметрами опять надо лезть в MSDN.

И это на таком простом примере с пимитивнишим врапером...
А что будет если логика будет сложнее? Несколько файлов? Несколько мест где надо проверить логику?...

---

лирическое отступление...

Однажды пришлось править код одного "программера со стажем" который не знал что такое смартпоинтеры и для чего надо писать обертки... я потритил несолько часов для того чтобы изменить формат генерируемого файла с такого

asd dfsg qrqwe adff qwrq
dfavgf qerwet asghs waet afhga

на такой

[asd]
param1=dfsg 
param2=qrqwe 
param3=adff 
param4=qwrq
[dfavgf]
param1=qerwet 
param2=asghs 
param3=waet 
param4=afhga

один клиент хотел первый формат, другой второй...

Правки такого типа в своем коде исполюзующем "навороты С++ на всю катушку" я вношу за минуты причем как правило тестирование багов не находит.

И самое смешное что другой программист со стажем(на этот раз без кавычек)не имевший раньше дел с "наворотами С++ на всю катушку" сел и спокойно прочитал мой код...

---

А теперь берем STL...

bool write_some_in_file3(char const* name)
{
    std::ofstream file(name, std::ios::out|std::ios::binary);
    if(!file)
        return false;
    file.write(name, strlen(name));
    file.flush();
    return file;
};

Написал не смотря в хелпы... ибо запоминать тут практически нечего...

А для работы ИМХО хорошей идеей является абстракция типа

struct binary_stream_reader
{
    virtual size_t read(void* buf, size_t size)=0;
    virtual bool is_valid()=0;
};
struct binary_reader
    :binary_stream_reader
{
    virtual bool seek(size_t pos)=0;
    virtual size_t pos()=0;
    virtual size_t size()=0;
};

Если пасать код под binary_reader то работа с файлом, блобом или еще какой структурой с произвольным доступом будет совершенно одинакова. А если писать под binary_stream_reader то вобще можно работать с любым потоком...


Думайте сами, решайте сами... какой вариант использовать для разработки приложений...

Я не спорю с тем что когда надо добратся до всех возможностей работы с файлами под виндой то от WinAPI ни куда не дется... но даже в этом случае я буду делать обертки аля второй вариант.
Ибо The devil is in the details. и чем деталей меньше тем лучше.

Здравствуйте, Voblin, Вы писали:

V>Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!
Трудно сказать... я стараюсь без них но иногда особенно при написании какой либо библиотеки они бывают очень полезны.
На пример посмоти реализацию boost::function фаил function_template.hpp и попробуй представить его без макросов из библиотеки boost::preprocessor...
Если не можешь то посмотри на boost::signals.
А теперь попробуй представить их вобще без макросов...
Если не можешь то тебе прямая дорога в Loki фаил Functor.h и учти что по функциональности и качеству реализации Liki::Functor близко не валялся с boost::function...

Здравствуйте, Voblin, Вы писали:

V>Ага, но при этом легко получить вариант a la Navision.

Дык, создай/купи/укради нормальную библиотеку предоставляющую примитивы предметной области и все будет ОК. Ну, и сам, как прикладник, не забывай про такие вещи как инкапсуляция.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>CMyClass& как параметр вызовов.

MSS>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.

Ну, на С можно не хуже:

#define f(obj) _f(&obj)
_f(MyStruct *obj) { ... }
...
MyStruct xxx;
f(xxx);

Или так:

_f() { ... }
...
MyStruct xxx;
f(xxx);

Так что реклама С как языка без неожиданностей мягко говоря лукавство.

А вот столь клон столь нелюбимой Явы — Шарп очень неплохо решает эту проблему:

f(ref MyStruct obj) { ... }
...
MyStruct xxx;
f(ref xxx);

Указание ref обязательно. Оно прекрасно выражает смысл. Все тоже самое можно и в С с С++, но только на уровне соглашений кодирования.

MSS>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.

Агащасблин. А про то, что указатель может быть NULL или черти чем ты не забыл? Ссылки как раз это устраняют. Так что тут пролема не в наличии фичи, а в плохом синтаксисе.

MSS>Namespaces и особенно оператор using.

MSS>Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.

MSS>Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.

Тут даже коментировать нечего. Бред да и только. Простраства имен самое разумное решение борьбы с перекрывающимися именами. С префиксами давно борятся все разумные люди. При некотором объеме кода они превращаются в тихий ужас.

MSS>Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.

А надо чтобы значил? Назави хоть один случай когда ты пострадал от использования операторов? А вот читать:

string a = "мыла";
string b = "Маша " + a + " раму." + "Вот " + "такие пироги.";

Куда проще чем:

char* a = "мыла";
char* b = strcat("Маша ", strcat(a, strcat(" раму.",
  strcat("Вот ", strcat("такие пироги.")))));

Одни скобки считать запаришся.

MSS>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй

Мля. А если strcat() залудить вызов отправляющий мыло админу о том, что строка сконкатинирована? Тоже ведь никто незаметит.

Если приведение семантически грамотно, то никаких проблем не возникает.

MSS>RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования?

Сам то понял что сказал? Причем тут полиморфизм и RTTI?

Что значит "поощрять не-полиморфные стили программирования"?

Процедурный стиль программирования полиморфный? Ну, а что ты за С тогда агетируешь? RTTI в С++ ругать можно и нужно, так как он убог до безобразия. Но уж хоть что-то. В дотнете рефлекшон прекрасно вписывается в ОО-концепции, позволяя расширять возможности среды и языка. Что-то ни одной жалобы на его использование. Чем ты это объяснишь?

MSS> Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы.

Ключевые слова здесь "как часть языка". У него есть идея фикс по которой все что можно нужно сделать независимой библиотекой. От того RTTI в С++ так убог.

MSS> Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?

Можно ссылки на то откуда ты взял "во-первых и во-вторых"?

MSS>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC?

Самому то не смешно?

MSS> Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.

Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной. А мы тут вмесете посмеемся.

MSS>Такое ощущение, что рефакторинг кода на Си++ должен состоять главным образом в выбрасывании из него этих маразмов, и приближении его к коду на Си .

Пока, что ты назвал одну фичу которую нужно дорабатывать и наговорил кучу глупости. Так что, думаю, рефакторинг в тоем стиле убил бы остатки разуменого в этом языке.

MSS>dynamic_cast само собой. Но это не единственный бред в Си++.

Мля. dynamic_cast — единственное небезопасное приведение типов в С++. Я балдею с этой агитации за каменный век.

MSS>Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.

Дурь — это конечно большая проблема. Только не программистов, а человечества в общем. Адни из них как раз борба с ОО без всяких оснований. Она ничем от обратоной (создания всего во что бы то ни стало в ОО-стиле) не отличается.

Низнаю что за задача "чтение SMART-данных". Но открывть файлы в конструкторе, а закрывать в деструкторе совершенно нормально. Особенно если чтение не тривиально и нужно хранить кучу контекстной информации.

MSS>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar.

И какое это имеет отношение к ОО и языку? Или маньяков нет только у CRT?

MSS>И нет никакой гарантии, что программист, которого нанимаешь, не будет маньяком какой-то заумной бредятины, и не свернет весь проект на ее использование. Рынок труда и HR таких гарантий уж точно не дадут.

Ага. Например маньяком С.

MSS>Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.

С каких это пор простой код было сложно писать? Вот просто решать сложные задачи — это действительно талант нужен. ОО-языки способствуют упрощению. Возможно С++ не самый удачный из ООЯ, но уж С — точно намного хуже.

MSS>А в силу сложности этого — лучше пользоваться инструментом, который не даст писать заумь. По крайней мере в ответственных проектах, где высока цена баги в человеко-часах, и превышает цену печати кода.

Запрещать нужно писать опасный и действительно плохопонятный код. "Заумь" — это придуманное тобой слово. И придумано оно исключительно чтобы повоспевать С. На С писать непонятный и плохочитаемый код ни чуть не сложнее чем на С++. В совое время я был очень рад перепрыгнуть с С на С++, потому как для описания задачи эмулировать ОО-подход на С.

MSS>И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.

Ага. И нопэд куда лучше чем разные там студии.

MSS>Я работал на Си++ годы. С 93 по эдак 99.

А можно узнать название компилятора который ты испльзовал в 93-ем?

MSS> И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.

Из С++ действительно можно было бы викинуть кучу бреда. Но пришлось бы добавить и кучу всего очень нужного. Тогда бы он возможно и для ГУИ подошел. А в современном виде использовать его для ГУИ — это мозахизм.

MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1.

Да уж зрелее не бывает.

MSS> А в системном программировании не прижился.

То-то Девпартнерс напрягается.

Да и написанием драйверов и ОС занимаются еденицы. А ты предлагаешь мэйнстриму идти в каменный век только потому, что тебе больше нравится С.

Уважаемый автор!
Вы читали книгу Страуструпа "Дизайн и эволюция Си++"?
Если нет — рекомендую настоятельно ее почитать.
Там написано как, зачем и почему он сделан таким, какой есть.
Совершенно согласен с Globus.

Здравствуйте, WolfHound, Вы писали:

WH>Трудно сказать... я стараюсь без них но иногда особенно при написании какой либо библиотеки они бывают очень полезны.
WH>На пример посмоти реализацию boost::function фаил function_template.hpp и попробуй представить его без макросов из библиотеки boost::preprocessor...
WH>Если не можешь то посмотри на boost::signals.
WH>А теперь попробуй представить их вобще без макросов...
WH>Если не можешь то тебе прямая дорога в Loki фаил Functor.h и учти что по функциональности и качеству реализации Liki::Functor близко не валялся с boost::function...

И почему в Шарпе есть все тоже самое, но без макросов?