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

Д>Нет, ты не понял. На собеседовании пусть напрягают, если по делу. Но делать "тестовые задания" на неделю объемом я не буду. Просто потому, что ценю свое время.

Невнимательно читаешь: тестовое задание не на неделю, а на 2-3 часа дизайна и 2-3 часа реализации. Формулировка, с которой мне, как кандидату, приходилось сталкиваться: "Мы надеемся, что в ближайшую неделю Вы сможете найти максимум 6 часов для выполнения нашего тестового задания".

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

ГВ>>>Александр Каширин очень точно подметил особенность простого кода. Вы никогда не сталкивались с проектами на десяток мегабайт очень-очень простого кода, где зависимости проявляются в самых неожиданных местах?
K>>Встречался. Но обьем кода совсем не мешал. Мой любимый метод навигации по коду — полнотекстовый поиск нужных идентификаторов по каталогу с сорсами. Часто приходится использовать и более точные инструменты поиска и навигации, но это уже по результатам полнотекстового поска, иногда с использованием резулярных выражений и только по частям идентификаторов.

ГВ>Вопрос в том, сколько времени уйдёт на эту самую навигацию.

Меньше (с). Я же не из любви к искусcтву так ищу. Возьмем сразу крайний случай — сколько у вас будет потеряно времени на исследование эффектов изменения какой-то переменной, которое описано в комментарии, расположенном в сорсе, где сама переменная не появляется ? В комментарии, понятно, и названия переменной нет, упомянуто представленное ей понятия, часть имени которого есть в имени переменной. Чтобы ничего такого не упустить, проводится сплошной поиск, а потом в найденном почти сразу видно нужное. Гораздо быстрее, чем если искать иными способами. В общем, полнотекстовый поиск с регэкспами — одна из важнейших фич code browser-а.

Один из наиболее простых примеров — найти закомментаренное применение того или иного метода.

ГВ>>>Да я тоже как-то не ратую за красоты ради красот. Просто наперёд трудно знать, что именно потребуется из механизмов C++. [...]

K>>Ситуация: есть код, есть опыт доработки этого кода, известно время, необходимое для каждого дополнительного улучшения; известно, что это время в данном проекте незначительно по сравнению со временем проработки планируемого обьема фич и внешних взаимодействий. Ситуация практически идеальна. Вопрос, зачем разрешать дополнительные фичи, если ни одного серьезного показателя это не улучит (поскольку они и так на максимуме), а ухудшить может вполне ?

ГВ>Во-первых, для каждого дополнительного улучшения наперёд всё знать невозможно.

Можно знать с достаточной точностью, которая по мере выполнения проектов повышается. Именно так и ведется планирование.

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

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

ГВ>Мотивация понятна: "чтобы не забыли сделать virtual destructor тогда, когда надо". Иными словами: "на всякий случай". Кстати, некогда я слышал о таком же "на всякий случай", но звучало это примерно так: "всё наследование должно быть виртуальным, все методы должны быть виртуальными". Не находите забавным?

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

Про виртуальное наследование — оно слишком мудрено. Сделали бы как в Java с интерфейсами вместо множественного и виртуального наследования (пусть даже с той же реализацией внутри), было бы куда понятнее.

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

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

Зависит от типичности использования и пользы от него. Все, что можно за-typedef-ить и спрятать в шареные хидеры, относительно приемлемо. В хидерах.

Mikhail

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

АК>Невнимательно читаешь: тестовое задание не на неделю, а на 2-3 часа дизайна и 2-3 часа реализации. Формулировка, с которой мне, как кандидату, приходилось сталкиваться: "Мы надеемся, что в ближайшую неделю Вы сможете найти максимум 6 часов для выполнения нашего тестового задания".

Даже в таком случае не стал бы. Ну если только компания сильно уж выдающаяся.

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

ГВ>Хотя то, как Вы расставили "конкурентные преимущества" наводит на интересные размышления. Получается, что менеджменту выгодны безответственные и непорядочные сотрудники. У них меньше конкурентых преимуществ перед остальными, следовательно, они менее требовательны к фирме-нанимателю.

Это смотря что нужно фирме-нанимателю. Если достаточны "безответственные и непорядочные сотрудники" и фирму устраивает результат их работы, то да, они более выгодны. Если вам нужны люди для выполнения ответственных работ, то вам и нужны более ответственные люди. Смотря какое качество работы (или какое отношение к работе) вам нужно...

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

ГВ>>Вопрос в том, сколько времени уйдёт на эту самую навигацию.

K>Меньше (с). Я же не из любви к искусcтву так ищу. Возьмем сразу крайний случай — сколько у вас будет потеряно времени на исследование эффектов изменения какой-то переменной, которое описано в комментарии, расположенном в сорсе, где сама переменная не появляется ? В комментарии, понятно, и названия переменной нет, упомянуто представленное ей понятия, часть имени которого есть в имени переменной. Чтобы ничего такого не упустить, проводится сплошной поиск, а потом в найденном почти сразу видно нужное. Гораздо быстрее, чем если искать иными способами. В общем, полнотекстовый поиск с регэкспами — одна из важнейших фич code browser-а.

K>Один из наиболее простых примеров — найти закомментаренное применение того или иного метода.

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

ГВ>>>>Да я тоже как-то не ратую за красоты ради красот. Просто наперёд трудно знать, что именно потребуется из механизмов C++. [...]

K>>>Ситуация: есть код, есть опыт доработки этого кода, известно время, необходимое для каждого дополнительного улучшения; известно, что это время в данном проекте незначительно по сравнению со временем проработки планируемого обьема фич и внешних взаимодействий. Ситуация практически идеальна. Вопрос, зачем разрешать дополнительные фичи, если ни одного серьезного показателя это не улучит (поскольку они и так на максимуме), а ухудшить может вполне ?

ГВ>>Во-первых, для каждого дополнительного улучшения наперёд всё знать невозможно.
K>Можно знать с достаточной точностью, которая по мере выполнения проектов повышается. Именно так и ведется планирование.

Для определённого круга изменений — да, но не для всего вообще.

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

Тогда что вы обсуждаете? Насколько я понял, вы пропонируете ограниченям в использовании "фич" C++.

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

Это не аргумент. Потому что начальство можно и должно "пинать". В том числе и РП-ов. Или начальник — это "вообще закон"? Для сведения: начальник — всего лишь коллега с другой работой, он тоже может ошибаться. Завтра ему взбредёт в голову, что работать нужно по стойке "смирно" и тоже подчиняться "патамушташеф"?

ГВ>>Мотивация понятна: "чтобы не забыли сделать virtual destructor тогда, когда надо". Иными словами: "на всякий случай". Кстати, некогда я слышал о таком же "на всякий случай", но звучало это примерно так: "всё наследование должно быть виртуальным, все методы должны быть виртуальными". Не находите забавным?

K>Не нахожу. Я видел код студентов, видел код индусов. Вижу, что отсутствие виртуального дестраутора по умолчанию реально создает несравнимо больше проблем, чем пользы. У тех, что уже не студенты, он просто всегда есть. В общем, гайдлайн про виртуальные деструкторы выстрадан персонально.

Так может быть, дело в том, что специалистов несравнимо меньше, чем... э... вы поняли?

K>Про виртуальное наследование — оно слишком мудрено. Сделали бы как в Java с интерфейсами вместо множественного и виртуального наследования (пусть даже с той же реализацией внутри), было бы куда понятнее.

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

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

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

K>Зависит от типичности использования и пользы от него. Все, что можно за-typedef-ить и спрятать в шареные хидеры, относительно приемлемо. В хидерах.

Понятно.

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

ГВ>Да я не оспариваю приемлемость такого способа поиска. Просто в большом количестве исходников сложнее рыться, чем в малом.

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

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

ГВ>Тогда что вы обсуждаете? Насколько я понял, вы пропонируете ограниченям в использовании "фич" C++.

Да, но как уже упоминали, это относится к т.н. "основной массе кода". Мудреный код выносится в места, которым уделяется обособленное внимание. Скажем, в библиотеки. Еще такой тюнинговый код попадается в боттлнеках, при нормальном девелопере — с кучей комментариев-варнингов вокруг.

K>>Не нахожу. Я видел код студентов, видел код индусов. Вижу, что отсутствие виртуального дестраутора по умолчанию реально создает несравнимо больше проблем, чем пользы. У тех, что уже не студенты, он просто всегда есть. В общем, гайдлайн про виртуальные деструкторы выстрадан персонально.

ГВ>Так может быть, дело в том, что специалистов несравнимо меньше, чем... э... вы поняли?

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

Я думаю, что в c++ надо было бы сделать квалификатор класса, запрещающий наследование, а при его отсутствии сделать деструктор виртуальным безальтернативно. Таким образом были бы исключены классы-наследники с невиртуальным деструктором, но польза от них весьма сомнительна.

K>>Про виртуальное наследование — оно слишком мудрено. Сделали бы как в Java с интерфейсами вместо множественного и виртуального наследования (пусть даже с той же реализацией внутри), было бы куда понятнее.

ГВ>Какое есть, такое есть. Я озвучил только то, что некогда слышал — этих брожений вокруг C++ всегда тьма-тьмущая.

Я студентам про него рассказываю под соусом "смотрите, какая дичь еще бывает, с которой в нормальных фирмах вам возиться не придется", на примере хитрого даймонда из c++ faq lite. Чтобы, если вдруг увидят на собеседовании, не называли некомпилируемым кодом.

Здравствуйте, DmitryMS.

5 Баллов.

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

ГВ>Хотя то, как Вы расставили "конкурентные преимущества" наводит на интересные размышления. Получается, что менеджменту выгодны безответственные и непорядочные сотрудники. У них меньше конкурентых преимуществ перед остальными, следовательно, они менее требовательны к фирме-нанимателю.

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

Бред какой-то. Советую постпать — все и пройдет

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

ГВ>Хотя то, как Вы расставили "конкурентные преимущества" наводит на интересные размышления. Получается, что менеджменту выгодны безответственные и непорядочные сотрудники. У них меньше конкурентых преимуществ перед остальными, следовательно, они менее требовательны к фирме-нанимателю.

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

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

ГВ>>Хотя то, как Вы расставили "конкурентные преимущества" наводит на интересные размышления. Получается, что менеджменту выгодны безответственные и непорядочные сотрудники. У них меньше конкурентых преимуществ перед остальными, следовательно, они менее требовательны к фирме-нанимателю.

E>Из чего вы сделали вывод о "выгоде" от безответственных и непорядочных сотрудников?

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

E>Я предпочту порядочного и ответственного непорядочному и безответственному, вот и всё.
E>Причем, ответственного буду стараться удержать уровнем компенсации.

А какова разница в компенсациях?

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

E>>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах.
АК>Смелое заявление. Особенно насчет виртуальных деструкторов. Если класс хоть от чего-то наследован, то не применять виртуальный деструктор — это высшая степень безграмотности. (Прошу не рассказывать мне о случаях, когда внутри класса нет ни одной виртуальной функции, а данные состоят только из элементарных типов: даже если это так, то я смотрю на будущее и допускаю появление таких элементов внутри класса при расширении функциональности программного продукта).
Это неверно. В таком случае деструктор может быть открытым и виртуальным или закрытымм и невиртуальным(Вроде, Саттер(с) )

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

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

E>>>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах.
АК>>Смелое заявление. Особенно насчет виртуальных деструкторов. Если класс хоть от чего-то наследован, то не применять виртуальный деструктор — это высшая степень безграмотности. (Прошу не рассказывать мне о случаях, когда внутри класса нет ни одной виртуальной функции, а данные состоят только из элементарных типов: даже если это так, то я смотрю на будущее и допускаю появление таких элементов внутри класса при расширении функциональности программного продукта).
LM>Это неверно. В таком случае деструктор может быть открытым и виртуальным или закрытымм и невиртуальным(Вроде, Саттер(с) )

Интересно, как предлагается грамотно уничтожать объект с невиртуальным закрытым деструктором, скажем, в таком случае:

class A
{
protected:
    ~A()
    {
        // do something specific
    }
};

class B : public A
{
protected:
    unsigned char* buffer;

    // something that can dynamically allocate buffer

public:
    B() : buffer(NULL) {}   
    ~B() 
    {
        if(buffer)
            delete [] buffer;
    }
};

class FactoryA
{
public:
    static A* getInstance() = 0;
};

class FactoryB
{
public:
    static A* getInstance()
    {
        return new B;
    }
};


int main()
{
    A* a = FactoryB::getInstance();

    // how to clean up here???

    return 0;
}

ИМХО, это типичный пример использования определенного круга задач ООП (в частности, полиморфизм). И как в данном случае обойтись без виртуального деструктора?

Здравствуйте, Александр Каширин, Вы писали:
E>>>>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах.
АК>>>Смелое заявление. Особенно насчет виртуальных деструкторов. Если класс хоть от чего-то наследован, то не применять виртуальный деструктор — это высшая степень безграмотности. (Прошу не рассказывать мне о случаях, когда внутри класса нет ни одной виртуальной функции, а данные состоят только из элементарных типов: даже если это так, то я смотрю на будущее и допускаю появление таких элементов внутри класса при расширении функциональности программного продукта).
LM>>Это неверно. В таком случае деструктор может быть открытым и виртуальным или закрытымм и невиртуальным(Вроде, Саттер(с) )
АК>Интересно, как предлагается грамотно уничтожать объект с невиртуальным закрытым деструктором, скажем, в таком случае:
<skipped>
АК>ИМХО, это типичный пример использования определенного круга задач ООП (в частности, полиморфизм). И как в данном случае обойтись без виртуального деструктора?
Согласен. У каждого правила есть свои исключения.

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

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

Когда все плохо, то обычно дело в яицах

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

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

_O_>>>Многие, кстати, не способны написать сортировку.
xog>>Зачем ее писать если есть стандартные способы реализации ?

B>Ну уж извините, сортировку пузырем написать должен каждый. Ибо помнить прадедов .

B>ОФФТОП мне часто приходится сортировать пузырем, т.к. далеко не везде есть готовые стандартные библиотечные реализации реализации.

Если уж какую-то одну помнить, то почему именно бабблсорт, а не квик или мердж сорт? Или уж на худой конец инсерт, кот. легче запомнить. Зачем помнить бабблсорт?


Due to its simplicity, the bubble sort is often used to introduce the concept of an algorithm to introductory programming students. However, some researchers such as Owen Astrachan have gone to great lengths to disparage bubble sort and its continued popularity in computer science education, recommending that it no longer even be taught.[1] The Jargon file, which famously calls bogosort "[t]he archetypical perversely awful algorithm", also calls bubble sort "the generic bad algorithm".[2] Don Knuth, in his famous The Art of Computer Programming, concluded that "the bubble sort seems to have nothing to recommend it, except a catchy name and the fact that it leads to some interesting theoretical problems", some of which he discusses therein.

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

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

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

_O_>>>>Многие, кстати, не способны написать сортировку.
xog>>>Зачем ее писать если есть стандартные способы реализации ?

B>>Ну уж извините, сортировку пузырем написать должен каждый. Ибо помнить прадедов .

B>>ОФФТОП мне часто приходится сортировать пузырем, т.к. далеко не везде есть готовые стандартные библиотечные реализации реализации.

Ael>Если уж какую-то одну помнить, то почему именно бабблсорт, а не квик или мердж сорт? Или уж на худой конец инсерт, кот. легче запомнить. Зачем помнить бабблсорт?

Часто приходится сортировать пузырём?Ужос
На самом деле практически единственный случай, когда это оправдано это если входной массив отличается от отсортированого на один элемент. То есть добавили один элемент или что-то изменилось и его позиция должна смениться, тогда да, за один проход всё отсортируется, за линейное время.
А применять пузырь часто и везде признак кривизны рук ->

P>На самом деле практически единственный случай, когда это оправдано это если входной массив отличается от отсортированого на один элемент.

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

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

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

Ага, понадобилось мне отсортировать массив из 10 элементов — мне квиксорт мутить? Я че быстрее вспомню — то и напишу.

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

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

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

J>Ага, понадобилось мне отсортировать массив из 10 элементов — мне квиксорт мутить? Я че быстрее вспомню — то и напишу.

А через пару месяцев программу кто-нибудь расширит и будет 10000 элементов, вот ведь здорово получится

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

J>>Ага, понадобилось мне отсортировать массив из 10 элементов — мне квиксорт мутить? Я че быстрее вспомню — то и напишу.
P>А через пару месяцев программу кто-нибудь расширит и будет 10000 элементов, вот ведь здорово получится

Ну врятли откроют 10000 планет, вращающихся вокруг Солнца