Re[14]: Блин, ну откуда столько криворуких? - О работе

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

IS>>>Ну и конечно не забывай о что мы говорим об “Виртуальном наследовании и почему его почти никто не применяет”.
ГВ>>Не только. Мы говорим ещё и том, что глупо запрещать использование виртуального наследования, коль в языке такой механизм есть.
K>Не согласен. Что с того, что он есть ? goto в языке тоже есть, и можно на ассемблерных вставках писать.

И goto тоже глупо запрещать. И ассемблерные вставки — тоже. И то и другое периодически если и не остро нужно, то может оказаться удобно. Я вот, например, не привык заморачиваться вопросом, как будет идеологически правильно выйти из 2-3 циклов сразу.

K>Аксиома: выбор стиля код программиста — не личное дело программиста, и вообще не его дело. Это дело тех, кто будет код поддерживать.

А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?

K>Самый правильный подход — заранее в документе компании оговорить, какие фичи использовать нельзя, и по необходимости расширять.

Угу, "надо, потому что надо": вводишь аксиому невнятого содержания и на её основании начинаешь что-то доказывать. Тут уже была история на месяц, примерно. Поищи в философии и священных войнах. Ключевые слова: "safe vs. unsafe".

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

Раз-другой прочтут — запомнят. Я не понимаю, неужели C++ настолько неподъёмен, что мозги перетрудятся от чтения документации?

K>Виртуальное наследование — как раз из этой оперы. Знание таблицы приоритетов операторов и sequence points наизусть — оттуда же.

"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором. А почему виртуальное наследование можно при этом запрещать, хотя его даже зазубривать не надо, достаточно один раз понять?

<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>

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

ГВ>"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Эта тема уже обсуждалась. Действительно, при уровне дохода, при котором +/- $500 еще имеет значение, з/п при выборе места работы стоит на первом месте.

Очень даже имеет значение. 500$ в Российской действительности весьма немалые деньги

E>Вам следовало сразу сказать, что вы были таким образом обмануты, в этом случае понятен источник ваших суждений. Увы, никто не застрахован от недобросовестных работодателей. Здесь можно посоветовать только одно — очень тщательно выбирать место работы.

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

E>При ныне сложившейся коньюнктуре, поиск работы программистом не представляет никакой сложности.
E>Скажите прямо и честно — если есть сомнения, что где-то еще эти "другие" смогут расчитывать на хотя бы такой же уровень оплаты труда, то вот тогда они и остаются там, где работают. Или это может объясняться элементарной ленью или "недостаточной силой духа", как вы выражаетесь. Всегда проще ныть и жаловаться, чем что-то реально делать.

Не согласен в принципе. Поиск работы — это стресс и очень хороший (имея за плечами не только IT-образование, но и психологическое, уверяю Вас, что это так на 100%). У Вас очень полярный взгляд на этот процесс. Многих людей процедура прохождения собеседований и все, что связано с поиском новой работы способны довести до клиники неврозов, но, при этом, они не являются плохими специалистами.

E>Халявщиков нужно гнать взашей, в этом нет никаких сомнений. Только зачастую обстоятельства складываются так, что приходится терпеть и халявщиков, поскольку замену придется учить, а это не всегда возможно по срокам. Что касается расчетов — есть трудовой договор, КЗОТ и суд.

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

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

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

E>Это вполне понятно и объяснимо. Возможно, я наблюдал несколько другие факты. Или те же, но был склонен интерпретировать их иначе.

Все возможно

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

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

E>>>Это не игра, далеко не игра. И принципы игр здесь неприменимы.
E>>>Вы же не станете покупать машину "на авось"?
M>>Советую очень внимательно ознакомиться с трудами Джона Нэша. Сильно удивитесь

E>Спасибо, курс теории игр мне читался в ВУЗе

Значит плохо читали

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

ГВ>И goto тоже глупо запрещать. И ассемблерные вставки — тоже. И то и другое периодически если и не остро нужно, то может оказаться удобно. Я вот, например, не привык заморачиваться вопросом, как будет идеологически правильно выйти из 2-3 циклов сразу.

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

K>>Аксиома: выбор стиля код программиста — не личное дело программиста, и вообще не его дело. Это дело тех, кто будет код поддерживать.

ГВ>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?

Я — не новичек. Но если мне подают код, ориентированный на новичков, то с ним работать гораздо легче. Спрашивается, нафига тогда выпендриваться ?

K>>Самый правильный подход — заранее в документе компании оговорить, какие фичи использовать нельзя, и по необходимости расширять.

ГВ>Угу, "надо, потому что надо": вводишь аксиому невнятого содержания и на её основании начинаешь что-то доказывать. Тут уже была история на месяц, примерно. Поищи в философии и священных войнах. Ключевые слова: "safe vs. unsafe".

Эта аксиома взялась из практики. Автор оригинального кода — это человек, который с ним работает меньше всего. Более 90% всех работы над этим кодом за все время его жизни, включая чтение и анализ, ведут потом другие люди. Включая время, когда этот перец давно уволился. С какого черта лысого один человек своим выпендрежем создает трудности всем остальным ? Он написал и ушел — в другой проект, например. А всем остальным это г-но саппортить и далее развивать, стараясь не нарваться на мину из-за использования не всем одинаково понятных фич языка.

ГВ>Раз-другой прочтут — запомнят. Я не понимаю, неужели C++ настолько неподъёмен, что мозги перетрудятся от чтения документации?

И через месяц забудут. Через полгода из-за какой-то неочевидной хрени с приведением типов и следующим из этого выбором перегруженных операторов все взорвется. Практика пересбора кода на всех поддерживаемых платформах, даже когда он написан вроде бы кросс-платформенно, и даже когда изменена всего одна строчка — оно не на пустом месте возникло. И так делают повсеместно в серьезных конторах. Один нюанс в работе компилетров, приводящий к разной работы на разных платформах — и все сдохло нахрен. И бывает это чаще, чем хотелось бы. И gcc используется реже, чем некоторым кажется. И gcc разных версий содержит разные баги, что тоже вносит свой вклад. Именно поэтому в больших серьезных системах код пишут настолько примитивно, насколько возможно, и стараются по минимуму лезть в фичи, которым менее 10-15 лет от роду. Все запреты неоднократно выстраданы на крешах.

ГВ>"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором.

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

ГВ> А почему виртуальное наследование можно при этом запрещать, хотя его даже зазубривать не надо, достаточно один раз понять?

Ну, понял. Разобрался. Выучил. Состояние "не могу работать с этой хренью" сменилось на "не переношу эту хрень, хочу видеть пять листов A4 с обоснованием, росписями и печатями под каждое применение".

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

E>>>>Это не игра, далеко не игра. И принципы игр здесь неприменимы.
E>>>>Вы же не станете покупать машину "на авось"?
M>>>Советую очень внимательно ознакомиться с трудами Джона Нэша. Сильно удивитесь

E>>Спасибо, курс теории игр мне читался в ВУЗе

M>Значит плохо читали

Скорее, не плохо, а неубедительно

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

K>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором.

K>Такой код — повод для немедленного отстранения от работы. Разработчик вместо работы занимается выпендрежем. Код к тому же ненадежен.

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

Здравствуйте, Александр Каширин, Вы писали:

АК>

АК>interface V
АК>{
АК>    void foo();
АК>}

АК>interface A extends V
АК>{
АК>    void foo();
АК>    void aar();
АК>}

АК>interface B extends V
АК>{
АК>    void foo();
АК>    void bar();
АК>}

АК>public class C implements A, B
АК>{
АК>    public void foo()
АК>    {
АК>    }

АК>    public void aar()
АК>    {
АК>    }

АК>    public void bar()
АК>    {
АК>    }

АК>    public static void run()
АК>    {
АК>        new C().foo();
АК>    }
АК>}
АК>

АК>Этот код прекрасно компилируется, не вызывая ошибок неоднозначности. Хотя метод foo() в обоих интерфейсах A и B якобы переопределен. А на самом деле, обратите внимание, "переопределение" этого метода не приводит к появлению новой имплементации метода: метод по-прежнему остается один, и его реализация также остается единственной и относится к интерфейсу V. Где Вы видите доминирование?

Для начала поясню, что я подразумеваю под доминированием при виртуальном
наследовании:

#include <iostream>

class IBase
{
public:
    virtual ~IBase() {}
    virtual void dominanceTest() = 0;
};

class BaseImpl: public virtual IBase
{
public:
    void dominanceTest()
    {
        std::cout << "Dominance!" << std::endl;
    }
};

class Derived 
    : public BaseImpl
    , public virtual IBase
{
};

int _tmain(int argc, _TCHAR* argv[])
{
    Derived test;
    test.dominanceTest();
    return 0;
}

Обратите внимание, что класс Derived наследует IBase двумя путями:
напрямую и через BaseImpl. Мы получили классический ромб с виртуальной
базой в корне (на самом деле в нашем случае скорее треугольник). На первый
взгляд может показаться, что данный пример не должен собираться, поскольку
Derived не содержит реализации чисто витруального метода dominanceTest,
унаследованного от IBase напрямую. На самом же деле всё прекрасно
собирается. VS2005 даже уведомляет меня о том, что:
"warning C4250: 'Derived' : inherits 'BaseImpl::BaseImpl::dominanceTest' via dominance"
Это и есть явление доминирования при виртуальном наследовании в C++.
Если же убрать виртульное наследование, то данный пример просто перестанет
компилироваться. Убери виртуальное наследование — доминирование исчезнет.

Как же объяснить подобное явление? Например, следующим образом: при виртуальном
наследовании "виртуально наследуются" не только поля данных витруальной
базы, но и указатель на таблицу виртуальных функций. Поэтому, когда в классе
BaseImpl появляется реализация dominanceTest(), то адрес этой функции заносится
в таблицу виртуальных функций класса IBase, которая одна-единственная. Поэтому,
если мы виртуально унаследуем Derived от IBase, объект Derived будет иметь
таблицу виртуальных функций, где все ячейки заполнены правильными адресами, поскольку
в ячейку для dominanceTest адрес был записан при реализации BaseImpl.
С точки зрения компилятора Derived является полноценным объектом,
хотя и не содержит реализации dominanceTest().

Теперь пример на Java:

[java]
public interface IBase {

public abstract void dominanceTest();

}

public class BaseImpl implements IBase {

public void dominanceTest() {
System.out.println("Java has dominance feature as well as C++ and Eiffel");
}

}

public class Derived extends BaseImpl implements IBase {

}

public class Root {

public static void main(String[] args) {

Derived test = new Derived();
test.dominanceTest();
}
}

Обратите внимание, что хотя класс Derived "implements IBase", никакой
реализации абстрактного метода dominanceTest() из IBase он не содержит.
И компилятор подобная ситуация на смущает. Пример собирается и работает
предсказуемым образом. Это похоже именно на явление доминирования при
виртуальном наследовании в C++.

Может быть я ошибаюсь, но если нечто выглядит как виртуальное наследование,
ведёт себя как виртуальное наследование, то — это и есть виртуальное
наследование.

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

E>>Эта тема уже обсуждалась. Действительно, при уровне дохода, при котором +/- $500 еще имеет значение, з/п при выборе места работы стоит на первом месте.
M>Очень даже имеет значение. 500$ в Российской действительности весьма немалые деньги

Да, до определенного уровня дохода.
При доходе в 3-4-5 К$, $500 уже не столь критично, и при выборе места работы вступают в силу другие критерии. В этом треде кто-то умный даже вывел процентаж

M>Не согласен в принципе. Поиск работы — это стресс и очень хороший (имея за плечами не только IT-образование, но и психологическое, уверяю Вас, что это так на 100%). У Вас очень полярный взгляд на этот процесс. Многих людей процедура прохождения собеседований и все, что связано с поиском новой работы способны довести до клиники неврозов, но, при этом, они не являются плохими специалистами.

Что тут можно сказать, люди разные бывают. Но в этой связи еще более странно, что люди, так боящиеся смены работы, "халявят". Казалось бы, должно быть совсем наоборот? Видимо, те, кто "халявит", как раз не боятся потерять работу?

M>А узнать у работника, что заставило его стать "халявщиком" не судьба? Таковы 99.9% всех Российских кАрпАрАций. Зачем интересоваться проблемами сотрудника, когда порще вытолкать его взашей и взять нового.

Ой ли? Сейчас очень серьезный дефицит специалистов, поэтому совсем не "проще".

M>Сотрудник хорош до тех пор, пока он накачивает карман шефа и, желательно, на халяву или близко к этому. Про суды — не смешите мои тапочки — Вы в какой стране живете? Много знаете прецендентов, когда удавалось отсудить у конторы невыплаченные деньги? Довольно часто, при попытке вернуть свое, можно лихо пострадать физически и это факт.

Увы, не могу не согласиться, что есть то есть.

M>Согласен полностью, но выгонят скорее не менеджера потому, что он очень хорошо умеет лизать задницу начальству и всегда руководство будет на его стороне. Примеров могу привести массу, причем из жизни, так называемых, "известных и уважаемых" контор.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Александр Каширин, Вы писали:

ГВ>>>"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором.

K>>Такой код — повод для немедленного отстранения от работы. Разработчик вместо работы занимается выпендрежем. Код к тому же ненадежен.

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

Я каждый раз глаза ломаю его читать. Приходится вспоминать, что происходит раньше — * или ++. На практике этой информацией пользоваться не приходится, и она выветривается.

Надежность и простота — основные характеристики кода. Этот код плохо читаем уже оттого, что далеко не все по пять лет пишущие плюсовики смогут сказать, что это конструкция делает. Не потому что тупые, а потому что подобного кода просто не пишут. Я не знаю где он у вас там часто встречается. Читая его, приходится аккуратно восстанавливать приоритет операций, поскольку скобками они не обозначены, а из явных приоритов кроме арифметических со школы мало кто что помнит — кроме тех, кто увлекается применением их по памяти и требует того же от других. Вы наверно и не встречали мест, где по сугубо практическим соображениям забанен stl и не особо рекомендуются namespaces. И вот еще мой любимый пример кода, который понять можно, но нормальный серьезный человек об него споткнется:

 switch(0) {default: cout << "Hello World!\n";}

Утверждение об эффективности тоже требует обоснования. Сможет ли оптимизатор привести ваш код к оптимальному машкоду ? Ему-то как раз сложные конструкции противопоказаны. Те, где активно применяются указатели, противопоказаны вдвойне...

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

K>Я каждый раз глаза ломаю его читать. Приходится вспоминать, что происходит раньше — * или ++. На практике этой информацией пользоваться не приходится, и она выветривается.
K>...
K>Читая его, приходится аккуратно восстанавливать приоритет операций, поскольку скобками они не обозначены

Ээээ... ммм... тут скобки не помогут

Что раньше выполняется — это определяется исключительно положением ++ относительнь указателя: прединкремент или постинкремент

K>Я не знаю где он у вас там часто встречается.

Ну, например, в исходных кодах стандартных библиотек С (особенно работа со строками и с памятью) и С++ (в том же STL — добрая половина работы с итераторами включает постинкременты прямо в операции).

K>Утверждение об эффективности тоже требует обоснования. Сможет ли оптимизатор привести ваш код к оптимальному машкоду ? Ему-то как раз сложные конструкции противопоказаны. Те, где активно применяются указатели, противопоказаны вдвойне...

Ну что же сложного в конструкции из одного выражения и двух постинкрементов?

А что Вы скажете о сложности такого кода:

if(ptr && ptr->method())
{
    yes();
    wow();
}
else
{
    no();
    never();
    out();
}

Тут есть примерно такое же мега-неудобство: нужно помнить, что стандартом языка С/С++ предусмотрено, что если в логическом выражении && первый операнд вернул 0, то второе даже не вычисляется (в данном случае — гарантия того, что обращения к памяти по адресу 0х00000000 не будет). Но ведь это же надо помнить! (!!!)

Неужели более читабельным и не менее эффективным, на Ваш взгляд, будет примерно так (тут уже помнить ничего не надо

bool y = false;

if(ptr)
{
    if(ptr->method()
    {
        yes();
        wow();
        y = true;
    }
}

if(!y)
{
    no();
    never();
    out();
}

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

K>Теперь пример на Java:

K>

K>public interface IBase {
    
K>    public abstract void dominanceTest(); 

K>}

K>public class BaseImpl implements IBase {

K>    public void dominanceTest() {
K>        System.out.println("Java has dominance feature as well as C++ and Eiffel");
K>    }

K>}

K>public class Derived extends BaseImpl implements IBase {

K>}

K>public class Root {

K>    public static void main(String[] args) {

K>        Derived test = new Derived();
K>        test.dominanceTest();
K>    }
K>}

K>Обратите внимание, что хотя класс Derived "implements IBase", никакой
K>реализации абстрактного метода dominanceTest() из IBase он не содержит.
K>И компилятор подобная ситуация на смущает. Пример собирается и работает
K>предсказуемым образом. Это похоже именно на явление доминирования при
K>виртуальном наследовании в C++.

Ну начнем с того, что в ответ на abstract в декларации интерфейса компилятор намекнет вам о неуместности "неприличных" слов

А во-вторых, нет здесь никакого абстрактного метода. Здесь есть задекларированный метод интерфейса, который должен быть реализован в классе, который объявляет о том, что поддерживает этот интерфейс. И его имплементация находится на одном из уровней иерархии. Все чрезвычайно просто, и никаких доминантов.

C>Если человек не знает, что такое шаблон, интерфейс, виртуальное наследование, виртуальные функции (собственно человек не зает Си++ >но кодирает на нем) как он может выбирать вариант реализации? Он будет делать такую реализацию, которая соответствует его уровню

как же они у вас пишут код то, методом копи-паста?

Здравствуйте, Александр Каширин, Вы писали:

АК>Здравствуйте, Kestrel, Вы писали:

АК>Ну начнем с того, что в ответ на abstract в декларации интерфейса компилятор намекнет вам о неуместности "неприличных" слов

Очень может быть. По бедности я пользуюсь только компилятором, входящим в сосав Eclipse 3.1.2.
Он не ругается.

АК>А во-вторых, нет здесь никакого абстрактного метода. Здесь есть задекларированный метод интерфейса, который должен быть реализован в классе, который объявляет о том, что поддерживает этот интерфейс. И его имплементация находится на одном из уровней иерархии. Все чрезвычайно просто, и никаких доминантов.

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

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

K>Здравствуйте, Александр Каширин, Вы писали:

АК>>Здравствуйте, Kestrel, Вы писали:

АК>>Ну начнем с того, что в ответ на abstract в декларации интерфейса компилятор намекнет вам о неуместности "неприличных" слов

K>Очень может быть. По бедности я пользуюсь только компилятором, входящим в сосав Eclipse 3.1.2.
K>Он не ругается.

АК>>А во-вторых, нет здесь никакого абстрактного метода. Здесь есть задекларированный метод интерфейса, который должен быть реализован в классе, который объявляет о том, что поддерживает этот интерфейс. И его имплементация находится на одном из уровней иерархии. Все чрезвычайно просто, и никаких доминантов.

K>Я не спорю с тем, что это не сложно. Я хочу сказать, что у такого поведения есть
K>прямой аналог в C++. И в C++ этот аналог называется виртуальное наследование.

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

K>Я не спорю с тем, что это не сложно. Я хочу сказать, что у такого поведения есть
K>прямой аналог в C++. И в C++ этот аналог называется виртуальное наследование.

Да нет же! Я как раз и утверждаю, что нет никакого прямого аналога в С++!
То, что вы называете множественным наследованием одного и того же интерфейса, на самом деле таковым не является: в Java это следует рассматривать как объявление: "Повторяю: класс таки да поддерживает этот интерфейс". Т.е. самого понятия множественного наследования здесь не существует (отдельной ветки в иерархии не создается), не говоря уже о виртуальном.

Здравствуйте, Александр Каширин, Вы писали:

АК>Здравствуйте, Kestrel, Вы писали:

K>>Я не спорю с тем, что это не сложно. Я хочу сказать, что у такого поведения есть
K>>прямой аналог в C++. И в C++ этот аналог называется виртуальное наследование.

АК>Да нет же! Я как раз и утверждаю, что нет никакого прямого аналога в С++!
АК>То, что вы называете множественным наследованием одного и того же интерфейса, на самом деле таковым не является: в Java это следует рассматривать как объявление: "Повторяю: класс таки да поддерживает этот интерфейс". Т.е. самого понятия множественного наследования здесь не существует (отдельной ветки в иерархии не создается), не говоря уже о виртуальном.

Небольшая таблица, где сравниваются примеры на C++ и Java, приведённые ранее.

Пункты
сравнения          C++                            Java
__________________________________________________________________________

Сущности           IBase,                      IBase,
                   BaseImpl, Derived           BaseImpl, Derived

IBase              IBase - абстрактный         IBase - интерфейс
                   базовый класс

Отношения          BaseImpl наследует          BaseImpl implements IBase
наследования       от IBase
                   Derived  наследует          Derived  implements IBase
                   от IBase
                   Derived наследует           Derived extends BaseImpl
                   от BaseImpl

Есть ли реализация
void dominanceTest()   нет                              нет
в IBase

Есть ли реализация
void dominanceTest()   да                                да
в BaseImpl

Есть ли реализация
void dominanceTest()   нет                              нет
в Derived

Коппилируется ли       да                                да
пример

Будет ли при вызове    да                                да
void dominanceTest()
бызвана реализация 
из класса BaseImpl

_________________________________________________________________

В чем разница между примерами на на C++ И Java, кроме терминологии?
Интересует не то, как называется то или иное свойство языка, а разница
в поведении.

Hello Геннадий,

E>> Если вы к своей работе относитесь безответственно, з/п ничего не
E>> изменит. Ответственность не регулируется з/п, вообще никак. Это
E>> качество самого человека, так же как и порядочность.

ГВ> Вот, кстати, вопрос. Если специалисту безотносительно его
ГВ> ответственности и порядочности будут платить на уровне, скажем так,
ГВ> рыночном, то во сколько оценивается его ответственность и
ГВ> порядочность? Можно — в процентах к базовой ставке.

Тут народ уже говорил, что имеет смысл менять работу если предложат ЗП на
20-25% и выше от текущей.
Вот и нужно держать соответствующую планку.

WBR,
Alexander Khokhlov

Posted via RSDN NNTP Server 2.0

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

ГВ>>И goto тоже глупо запрещать. И ассемблерные вставки — тоже. И то и другое периодически если и не остро нужно, то может оказаться удобно. Я вот, например, не привык заморачиваться вопросом, как будет идеологически правильно выйти из 2-3 циклов сразу.

K>Кто-то бросает исключение. Я обычно делаю break. [...] А с goto у меня никогда нет уверенности, является ли такой выход корректным.

У меня тоже не всегда есть такая уверенность. Здесь лучше всего помогает чтение стандарта и тесты. Большая часть вопросов и неуверенности снимается сходу. Про ошибки компилятора намеренно не упоминаю, это разговор особый. Он может и goto неправильно обработать, и break, и ещё много чего.

K>>>Аксиома: выбор стиля код программиста — не личное дело программиста, и вообще не его дело. Это дело тех, кто будет код поддерживать.
ГВ>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?
K>Я — не новичек. Но если мне подают код, ориентированный на новичков, то с ним работать гораздо легче. Спрашивается, нафига тогда выпендриваться ?

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

K>>>Самый правильный подход — заранее в документе компании оговорить, какие фичи использовать нельзя, и по необходимости расширять.
ГВ>>Угу, "надо, потому что надо": вводишь аксиому невнятого содержания [...]
K>Эта аксиома взялась из практики. Автор оригинального кода — это человек, который с ним работает меньше всего. Более 90% всех работы над этим кодом за все время его жизни, включая чтение и анализ, ведут потом другие люди. Включая время, когда этот перец давно уволился. С какого черта лысого один человек своим выпендрежем создает трудности всем остальным ?

Если эти самые "остальные" мотивируют свои трудности необходимостью изучить инструмент, то это сугубо их личные проблемы. Инструмент надо знать и уметь.

K>Он написал и ушел — в другой проект, например. А всем остальным это г-но саппортить и далее развивать, стараясь не нарваться на мину из-за использования не всем одинаково понятных фич языка.

С чего это Вы взяли, что на выходе у автора неизбежно получится г-но? Это всего лишь код на языке программирования и всё. Если фичи не понятны, то в них нужно разобраться, а не бравировать своим непониманием, прикрывая его маской заботы о ближнем.

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

1. В некоторых случаях использование фичи X влечёт проблемы.
2. Проблемный код является г-ном.
Вывод: всякое использование фичи X — г-но.

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

ГВ>>Раз-другой прочтут — запомнят. Я не понимаю, неужели C++ настолько неподъёмен, что мозги перетрудятся от чтения документации?

K>И через месяц забудут. Через полгода из-за какой-то неочевидной хрени с приведением типов и следующим из этого выбором перегруженных операторов все взорвется. Практика пересбора кода на всех поддерживаемых платформах, даже когда он написан вроде бы кросс-платформенно, и даже когда изменена всего одна строчка — оно не на пустом месте возникло. И так делают повсеместно в серьезных конторах. Один нюанс в работе компилетров, приводящий к разной работы на разных платформах — и все сдохло нахрен. И бывает это чаще, чем хотелось бы.

Это всё понятно и разумно. Только причём тут запрет использования неких фич ввиду их "непонятности"? Если есть сугубо технические причины отказаться от использования, скажем, некоего варианта наследования, то не вижу ровным счётом никакой проблемы. Наоборот, двумя руками "за" развитие такой базы знаний. Например, у меня был случай, когда пришлось отказаться от довольно хитрого сочетания наследования и шаблонов (ошибки VC6). Только это ведь не связано с трудностями изучения языка, правильно?

Иными словами, Вы сейчас передёргиваете путём подмены основания.

K>И gcc используется реже, чем некоторым кажется. И gcc разных версий содержит разные баги, что тоже вносит свой вклад. Именно поэтому в больших серьезных системах код пишут настолько примитивно, насколько возможно, и стараются по минимуму лезть в фичи, которым менее 10-15 лет от роду.

Это тоже так. Но у примитивизации есть и оборотная сторона, прежде всего связанная с увеличением объёма исходников. "Комбинаторный взрыв", знаете ли.

K>Все запреты неоднократно выстраданы на крешах.

Не стоит обобщать эту красивую легенду. На самом деле, запреты могут копироваться из всяческих good practices на основании одной только интуиции.

ГВ>>"Наизусть", действительно, можно и не зазубривать. Но это не повод не писать, например, "while(*dest++ = *src++);" для копирования строки или последовательности с нулевым терминатором.
K>Такой код — повод для немедленного отстранения от работы. Разработчик вместо работы занимается выпендрежем. Код к тому же ненадежен.

Началось... Ладно, чтобы не вдаваться в длинные рассуждения, прочтите Safe or Unsafe — this is the question, Понимание сути вопроса, Safe vs. unsafe — 2 в "Философии" и ещё резюмирующие ветки в "СВ": Резюме к safe vs. unsafe, Генеральная линия партии и По просьбам трудящихся....

ГВ>> А почему виртуальное наследование можно при этом запрещать, хотя его даже зазубривать не надо, достаточно один раз понять?
K>Ну, понял. Разобрался. Выучил. Состояние "не могу работать с этой хренью" сменилось на "не переношу эту хрень, хочу видеть пять листов A4 с обоснованием, росписями и печатями под каждое применение".

Главное, что "разобрался и выучил". То, что "хочется видеть" что-то там — дело десятое. Это совсем не повод запрещать окружающим это самое что-то использовать.

<< Под музыку: Аквариум — Новая Песня О Родине >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>

	От:	Дарней
	Дата:	11.07.06 08:54
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	11.07.06 09:01
Оценка:

	От:	Дарней
	Дата:	11.07.06 09:04
	Оценка:

	От:	Menestrel
	Дата:	11.07.06 09:19
	Оценка:

	От:	Menestrel
	Дата:	11.07.06 09:21
	Оценка:

	От:	Александр Каширин
	Дата:	11.07.06 10:21
	Оценка:

От:	khap	https://khorost.net
Дата:	11.07.06 14:31
Оценка: