Re[24]: Чем становится C++? - Философия программирования

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

A>Ок, то есть ты предлагаешь мне, который пишет под embedded, использовать везде виртуальные деструкторы только потому, что в своем мейнстриме ты можешь чего-то там напортачить?

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

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

J>Надо набирать нормальных разработчиков и устраивать взаимный code review.

"нормальный разработчик" — это понятие растяжимое, а применение C++ увеличивает порог этого понятия многократно. Чтобы писать на C++, нужно иметь знаний намного больше, чем чтобы писать на Яве. И знания эти на 99% не имеют никакого отношения к основной задаче разработчика — решать проблемы заказчика.

J>ПМ должен заниматься управлением, общением с заказчиком, а не залезанием в код, который пишут его программисты.

А не ты ли писал перед этим, что "нужен очень грамотный ПМ, который сможет разбираться во всех присылаемых патчах и коммитах, отсеивать некачественное, по возможности исправлять". Так кто тут у нас понятия подменяет?
Все зависит от того, как трактуется понятие "ПМ" — а в разных фирмах оно трактуется по разному. Назови эту должность старшим разработчиком, руководителем группы, или как-то еще — суть от этого не изменится, и делать эту работу все равно кому-то нужно.

J>Кстати, аргумент "а на java можно набирать кого угодно, потому что язык проще" не работает: мои знакомые ПМы имеют много проблем с такими программистами на java, которые умудряются писать на этому суперязыке редкостную ахинею. Да, прога не падает в корку по access violation, но зато она тормозит, жрет море памяти и вылетает по NullPointerException.

Ты думаешь, на С++ они бы что-то лучшее написали?

Чрезмерно экономить на зарплатах тоже не стоит, хотя использование Явы и подталкивает к этому некоторых начальников

J>То, что задача типовая, не является ее упрощением, если ты пишешь ее с нуля.

Ну если не учитывать опыт других людей — тогда верно, не является

J>А вот спроектировать нечто универсальное типа 1С или SAP R/3 — даже ты такую задачу простой не назовешь.

Как и написание любого другого универсального движка.

J>Мне вот очень не нравится, когда в процессе обсуждения происходит подмена понятий. Мы начали обсуждение с бага, который можно внести очень редко, и его можно избежать при помощи анализа, который, очевидно, займет больше времени, чем отсутствие анализа. А теперь вдруг выясняется, что мы попутно обсуждаем программы, написанные с нуля.

Разработка программы — не одномоментный процесс, и во время разработки внести такой баг можно с немаленькой вероятностью. Где тут подмена?

J>ОК. Я не считаю, что для программ, написанных с нуля, время проектирования для разных языков различается в разы. А при грамотном проектировании реализация будет очевидной и предсказуемой по срокам.

Вероятно, ты просто не имел возможности сравнить.

J>Есть море сишного кода, вообще без классов и ГЦ, на котором построены сложнейшие системы.

Угу. всего то несколько лет отладки... зато все-таки работает!

J>например, функторы, биндеры, итераторы.

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

J>Если я УЖЕ что-то знаю, то вести разговор со МНОЙ о том, как МНЕ это сложно изучить — бессмысленно, потому что я УЖЕ обладаю этими знаниями, а не собираюсь их получить, а ты пытаешься меня от этого отговорить.

А я например НЕ уверен в том, что я УЖЕ знаю "китайский язык". И жизнь не устает подбрасывать мне доказательства — наподобие статической локальной переменной, которая вдруг обрушивает программу при ее инициализации. Ну кто бы мог подумать! А на первый взгляд — никаких граблей тут быть не может

Число людей, которые действительно хорошо знают эту область в нашей стране, измеряется десятками, и уверенность в том, что "я все уже знаю" — это всего лишь следствие ограниченного кругозора.

J>Ну, значит, я знаю, где копать, чтобы не напороться на высоковольтный кабель.
J>Тоже скилл полезный.

см. выше

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

S>Кстати, отображалку таблиц пришлось писать всего лишь из-за того, что IE 4.5
S>(давно дело было) HTML-таблицу размером всего-то 1000x1000 ячеек открывал
S>около получаса, выжирая около гига памяти.

А нафига может понадобиться HTML-таблица 1000x1000 ячеек

Hello, Трурль!
You wrote on Fri, 24 Dec 2004 06:29:56 GMT:

S>> Кстати, отображалку таблиц пришлось писать всего лишь из-за того, что
S>> IE 4.5 (давно дело было) HTML-таблицу размером всего-то 1000x1000 ячеек
S>> открывал около получаса, выжирая около гига памяти.

Т> А нафига может понадобиться HTML-таблица 1000x1000 ячеек

Confusion Matrix такая. Размер зависит от входных данных. Задача была
переделать все так, чтоб программа при ее показе не сильно тормозила и не
падала.

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 delta

Hello, Дарней!
You wrote on Fri, 24 Dec 2004 05:01:51 GMT:

S>> Кстати, отображалку таблиц пришлось писать всего лишь из-за того, что
S>> IE 4.5 (давно дело было) HTML-таблицу размером всего-то 1000x1000 ячеек
S>> открывал около получаса, выжирая около гига памяти. Зато все насквозь
S>> объектно и полиморфно. Потом, правда, это дело пофиксили без особого
S>> ущерба для объектности

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

Д> Если бы вместо борьбы с виртуальными деструкторами
Да я с ними не борюсь — просто не использую, если не нужны.

Д> ты читал книгу "банды четырех" повнимательнее, то нашел бы там паттерн
Д> Flyweight, который позволил бы уменьшить издержки памяти не на 5%, а в
Д> разы.

В моих случаях — не позволил бы.

Д> Но это, конечно же, не наш путь

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

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 delta

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

S>В моих случаях — не позволил бы.

Чем же таким особенным отличается твой случай?

S>Абсолютно. Flyweight реализовывать куда геморройней, чем отказаться от
S>ненужных виртуальных деструкторов. Разницы по памяти никакой, по скорости —
S>Flyweight однозначно проигрывает.

Разница по памяти не "никакая", а в разы. Хотя конечно зависит от радиуса кривизны.

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

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

J>>Надо набирать нормальных разработчиков и устраивать взаимный code review.

Д>"нормальный разработчик" — это понятие растяжимое, а применение C++ увеличивает порог этого понятия многократно. Чтобы писать на C++, нужно иметь знаний намного больше, чем чтобы писать на Яве. И знания эти на 99% не имеют никакого отношения к основной задаче разработчика — решать проблемы заказчика.

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

J>>ПМ должен заниматься управлением, общением с заказчиком, а не залезанием в код, который пишут его программисты.

Д>А не ты ли писал перед этим, что "нужен очень грамотный ПМ, который сможет разбираться во всех присылаемых патчах и коммитах, отсеивать некачественное, по возможности исправлять". Так кто тут у нас понятия подменяет?
Ты. Потому что я это писал про опен-сорсные проекты.
А ты потом возразил, что в закрытых нужно делать то же самое, с чем я не согласился.
Или это не так?

Д>Все зависит от того, как трактуется понятие "ПМ" — а в разных фирмах оно трактуется по разному. Назови эту должность старшим разработчиком, руководителем группы, или как-то еще — суть от этого не изменится, и делать эту работу все равно кому-то нужно.
"эту работу" — это какую?
если code review — с этим вполне способны справиться программисты за соседними столами.
если дизайн до кодирования — да, нужен более опытный человек (один или несколько — зависит от проекта), назовем его старшим разработчиком.
если общее управление и общение с заказчиком — ПМ.
Причем тут язык программирования — убей, не пойму.

J>>Кстати, аргумент "а на java можно набирать кого угодно, потому что язык проще" не работает: мои знакомые ПМы имеют много проблем с такими программистами на java, которые умудряются писать на этому суперязыке редкостную ахинею. Да, прога не падает в корку по access violation, но зато она тормозит, жрет море памяти и вылетает по NullPointerException.

Д>Ты думаешь, на С++ они бы что-то лучшее написали? :) Чрезмерно экономить на зарплатах тоже не стоит, хотя использование Явы и подталкивает к этому некоторых начальников ;)
Нет, не думаю, поэтому и говорю, что язык не играет роли, если мы набираем на работу профессиональных грамотных программистов.

J>>То, что задача типовая, не является ее упрощением, если ты пишешь ее с нуля.

Д>Ну если не учитывать опыт других людей — тогда верно, не является :)
Опыт автоматизации заборостроительного совсем не обязательно поможет при автоматизации сваезабивательного. :)

J>>А вот спроектировать нечто универсальное типа 1С или SAP R/3 — даже ты такую задачу простой не назовешь.

Д>Как и написание любого другого универсального движка.
Видишь, как мы хорошо друг друга понимаем :)

J>>Мне вот очень не нравится, когда в процессе обсуждения происходит подмена понятий. Мы начали обсуждение с бага, который можно внести очень редко, и его можно избежать при помощи анализа, который, очевидно, займет больше времени, чем отсутствие анализа. А теперь вдруг выясняется, что мы попутно обсуждаем программы, написанные с нуля.

Д>Разработка программы — не одномоментный процесс, и во время разработки внести такой баг можно с немаленькой вероятностью. Где тут подмена?

Разработка программы — это и не непрерывный процесс.
Согласись, удалить можно только то, что уже есть :)
Т.е. человек вначале должен спроектировать классы и их взаимодействие, а сюда входит и выбор стратегии владения.
Далее, тот, кто реализует эти классы и стратегию владения, знает о ней, посему ошибку может внести по очень большой глупости.
Далее, тот, кто реализует логику внутри, должен руководствоваться какими-то соображениями, чтобы решить, что в данном месте ему нужно удалить объект. Из чего он может исходить, кроме как из уже известной политики владения?
Далее, тот, кто вносит изменения в уже написанный код, действует по аналогии, т.е. если в коде удаляется объект, он его тоже удалит, если не удаляется — он его удалять не будет. А если и решит, что удалять надо или, наоборот, нужно убрать удаление, он в своем решении будет исходить опять же из известной политики владения, иначе можно легко посадить обсуждаемый баг или создать утечку.

J>>ОК. Я не считаю, что для программ, написанных с нуля, время проектирования для разных языков различается в разы. А при грамотном проектировании реализация будет очевидной и предсказуемой по срокам.

Д>Вероятно, ты просто не имел возможности сравнить.
Все может быть.

J>>Есть море сишного кода, вообще без классов и ГЦ, на котором построены сложнейшие системы.

Д>Угу. всего то несколько лет отладки... зато все-таки работает! :))
Ты утверждаешь, что для java-приложений не бывает нескольких лет отладки?
Мой опыт говорит об обратном.

J>>например, функторы, биндеры, итераторы.

Д>приведение к базовому типу по указателю для них и не предусматривается логикой их использования.

Не так. Не предусматривается динамическое создание и удаление через указатель на базовый класс.
В остальном — легко. Приведение к указателю или ссылке на базовый тип — постоянно используемая операция.
возьмем иерархию прямо из Стандарта (24.3.3):

   struct bidirectional_iterator_tag: public forward_iterator_tag {};
   struct random_access_iterator_tag: public bidirectional_iterator_tag {};

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

Д>А если там используется открытое наследование — значит, можно считать это недоработкой.
Вот уж поистине странное утверждение. А как же принцип Лисков? Разве итератор с произвольным доступом не может использоваться как двунаправленный или однонаправленный?
Или, может быть, функторы не являются унарными или бинарными функциями?
Если нет, тогда в чем проблема объявления из Стандарта (20.3.1, 20.3.2):

template <class Arg1, class Arg2, class Result>
struct binary_function {
   typedef Arg1 first_argument_type;
   typedef Arg2 second_argument_type;
   typedef Result result_type;
};

template <class T> struct plus : binary_function<T,T,T> {
   T operator()(const T& x, const T& y) const;
};

J>>Если я УЖЕ что-то знаю, то вести разговор со МНОЙ о том, как МНЕ это сложно изучить — бессмысленно, потому что я УЖЕ обладаю этими знаниями, а не собираюсь их получить, а ты пытаешься меня от этого отговорить.

Д>А я например НЕ уверен в том, что я УЖЕ знаю "китайский язык". И жизнь не устает подбрасывать мне доказательства — наподобие статической локальной переменной, которая вдруг обрушивает программу при ее инициализации. Ну кто бы мог подумать! А на первый взгляд — никаких граблей тут быть не может :)
Д>Число людей, которые действительно хорошо знают эту область в нашей стране, измеряется десятками, и уверенность в том, что "я все уже знаю" — это всего лишь следствие ограниченного кругозора.

Все знать невозможно ни в одной области.
Вот ты как ответишь на вопрос о том, знаешь ли ты русский язык?
Скорее всего, ты ответишь, что знаешь, и этот твой ответ не будет означать, что ты знаешь его полностью и досконально или хотя бы на уровне доктора наук по филологии.
Когда ты говоришь, что знаешь русский, ты подразумеваешь, что 99% случаев употребления тобой русского языка не вызывает проблем ни у тебя, ни у воспринимающей стороны. При этом ты знаешь, где в инете лежат словари и разъяснения правил русского языка, и в оставшемся проценте случаев не постесняешься заглянуть в них.

Так что если тебя коробит, когда я говорою, что знаю С++, можешь слово "знаю" заменить на "знаю достаточно для того, чтобы не испытывать трудностей при его использовании в 99% случаев".

J>>Ну, значит, я знаю, где копать, чтобы не напороться на высоковольтный кабель.
J>>Тоже скилл полезный.

Д>см. выше
см. выше :)

Hello, Дарней!
You wrote on Fri, 24 Dec 2004 08:03:56 GMT:

S>> В моих случаях — не позволил бы.

Д> Чем же таким особенным отличается твой случай?

Да тем, что память зря и так не тратиться. У объекта есть две координаты,
ширина, высота, указатель (или индекс) на текст, цвет фона. Эти данные
по-любому придется хранить в памяти, поскольку вычислять их долго. А дальше
выбираем — либо используем статический полиморфизм, без виртуальных функций
и их оверхеда по памяти, либо развлекаемся с flyweight. На жабе/шарпе
выбирать, конечно, не приходится, там объектов без оверхеда не бывает. Есть,
конечно, еще один вариант — писать все в сишном стиле, без объектов вовсе

S>> Абсолютно. Flyweight реализовывать куда геморройней, чем отказаться от
S>> ненужных виртуальных деструкторов. Разницы по памяти никакой, по
S>> скорости — Flyweight однозначно проигрывает.

Д> Разница по памяти не "никакая", а в разы.
Ты просто не понимаешь, что волшебства не бывает.

Д> Хотя конечно зависит от радиуса кривизны.
Еще как.

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 delta

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

S>Да тем, что память зря и так не тратиться. У объекта есть две координаты,
S>ширина, высота, указатель (или индекс) на текст, цвет фона. Эти данные
S>по-любому придется хранить в памяти, поскольку вычислять их долго.

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

S>Ты просто не понимаешь, что волшебства не бывает.

Это ты просто не понимаешь, о чем вообще речь шла в книге.

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

Д>Я просто говорю о том, что если ты пишешь в какой-то узкой нише ...

А я говорю о том, что приложения для десктопа с виндоуз и являются узкой нишей для С++.

Советую перечитать D&E на предмет того, для каких задач проектировался этот язык.

Hello, Дарней!
You wrote on Fri, 24 Dec 2004 09:32:22 GMT:

S>> Да тем, что память зря и так не тратиться. У объекта есть две
S>> координаты, ширина, высота, указатель (или индекс) на текст, цвет фона.
S>> Эти данные по-любому придется хранить в памяти, поскольку вычислять их
S>> долго.

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

Это ты не подумавши сказал

Какие такие накладные расходы для объектов,
лежащих в векторе? Заметь — не указателей на объекты, а именно объектов? И,
собственно, с чего спич начался — на кой черт объектам в этом случае
виртуальные деструкторы?

S>> Ты просто не понимаешь, что волшебства не бывает.

Д> Это ты просто не понимаешь, о чем вообще речь шла в книге.

Да-да, тупой я как пробка, есть такой недостаток.

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 delta

Hello, Alxndr!
You wrote on Fri, 24 Dec 2004 09:33:44 GMT:

Д>> Я просто говорю о том, что если ты пишешь в какой-то узкой нише ...

A> А я говорю о том, что приложения для десктопа с виндоуз и являются узкой
A> нишей для С++.

Советую перечитать D&E на предмет того, для каких
A> задач проектировался этот язык.

Да какая разница — узкая ниша или широкая? Дарней-то утверждал буквально
следующее "Значит — или ты делаешь виртуальный деструктор, или делаешь
наследование закрытым (еще лучше — агрегируешь объект). Уродцы наподобие
открытого наследования без виртуального дестркутора не должны иметь права на
существование."
То есть — нигде и ни когда

А потом вдруг оказывается, что в узких нишах
все же можно

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 delta

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

JИли мы отсеем программера на С++ потому, что у него знаний больше?

Потому что он больше денег требует

При этом, при одинаковой производительности труда. (нет, я говорю не про скорость написания кода. Я говорю про скорость приближения к результату)

J>Или это не так?

Прочитай внимательно и поймешь, что не так.

J>Нет, не думаю, поэтому и говорю, что язык не играет роли, если мы набираем на работу профессиональных грамотных программистов.

Дьявол, как всегда, в деталях. В данном случае — в цене.

J>Опыт автоматизации заборостроительного совсем не обязательно поможет при автоматизации сваезабивательного.

Значит, хреновый это опыт.

J>Видишь, как мы хорошо друг друга понимаем

J>Далее, тот, кто вносит изменения в уже написанный код, действует по аналогии, т.е. если в коде удаляется объект, он его тоже удалит, если не удаляется — он его удалять не будет. А если и решит, что удалять надо или, наоборот, нужно убрать удаление, он в своем решении будет исходить опять же из известной политики владения, иначе можно легко посадить обсуждаемый баг или создать утечку.

Вот мы и до этого дошли. Политику владения надо сначала продумать, потом — записать в документации, потом — реулярно проверять, что никто ни про что не забыл и нигде не накосячил.

J>Ты утверждаешь, что для java-приложений не бывает нескольких лет отладки?

оптимизации — возможно. отладки — крайне маловероятно.

J>Вот оно и есть — приведение к ссылке на базовый тип. Очевидно, с тем же успехом можно было бы применить и указатель на базовый тип.

Ключевое слово здесь — "ссылка". А за указатель в таком месте надо нещадно бить по рукам.

J>Когда ты говоришь, что знаешь русский, ты подразумеваешь, что 99% случаев употребления тобой русского языка не вызывает проблем ни у тебя, ни у воспринимающей стороны.

99% в какой области?

Можно например сказать, что "знание русского языка" подразумевает знание нескольких матов и умение правильно ответить на вопрос "ты меня уважаешь"?

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

J>нормальный — значит, знающий язык достаточно, чтобы писать на нем без явных ошибок, как в самих конструкциях языка, так и в дизайне.
J>Да, для С++ надо иметь знаний больше. Но если мы берем двух человек, которые умеют производить одинаково надежный код на разных языках, то какая нам разница, что это за языки? Или мы отсеем программера на С++ потому, что у него знаний больше?

Разница очень простая. Люди с одинаковыми скилами будут способны написать и отладить бошьше кода и смогут разобраться с более сложной системой.