Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, jhfrek, Вы писали:
J>>Здравствуйте, Denwer, Вы писали:
D>>>Если так рассуждать, то можно нанимать например переводчика, который даже не знает английских букв
J>>... и не может рассказать ни одного правила грамматики. Но зато переводит на лету, без ошибок и с учетом менталитета англичан и россиян — я за такого переводчика. Если бы я отвечал за прием переводчиков на работу, я бы взял его, а не вчерашнего студента, который наизусть знает все правила и запинается в реальной жизни.
I>Если переводчик не знает английских букв то крути не крути, он не сможет переводить в принципе.
Это еще почему?
Тот-же google translate наура переводит работая абстракциями на ровне слов и предложений, ничего не зная о буквах.
Тот-же ребенок 4-х лет пообщавшись несколько месяцев со сверстниками на ура переводит просьбу одного который говорит только по английски другому который говорит только на хинди. Совершенно не зная ничего о буквах данных языков (уж на хинди точно).
Тот-же другой знакомый мульти-лингвист утверждает что он готов изучить разговорный язык до бытового уровня только на уровне анализа устной речи — т.е. никаких букв, вообще при отсутсвия доступа к писменным источникам.
Более того, переводчики как-то же переводят с языков где букв как таковых вообще нет.
Вообщем буквы точно не причем.
Re: Виртуальный деструктор при множественном наследовании.
Здравствуйте, Denwer, Вы писали:
D>Последние два месяца прорезюмировал просто толпу соискателей на программистов по с++. Каково было мое удивление что 90% людей не знаю ДЛЯ ЧЕГО НУЖЕН ВИРТУАЛЬНЫЙ ДЕСТРУКТОР. Как такое может быть? Куда делись настоящие программситы, а не оходники за деньгами? Что творится с людьми?
Эта тема навела на следующие рассуждения:
Класс наследуется от двух веток, в истоках одной деструктор виртуальный, в истоках второй нет, и мы его удаляем по указателю на ту ветку, где виртуальный. Будут ли вызваны все деструкторы?
Например:
struct A {
~A() {} // Non-virtual.
};
struct B {
virtual ~B() {}
};
struct C : public A, public B {}
B* pc = new C;
delete pc; // будет ли здесь вызван A::~A() ?
Вот так по памяти и не скажу... Надо смотреть.
Если найду раньше вас — напишу.
Re[2]: Виртуальный деструктор при множественном наследовании
Здравствуйте, de_banderas, Вы писали:
_>Здравствуйте, Denwer, Вы писали:
D>>Последние два месяца прорезюмировал просто толпу соискателей на программистов по с++. Каково было мое удивление что 90% людей не знаю ДЛЯ ЧЕГО НУЖЕН ВИРТУАЛЬНЫЙ ДЕСТРУКТОР. Как такое может быть? Куда делись настоящие программситы, а не оходники за деньгами? Что творится с людьми?
_>Эта тема навела на следующие рассуждения: _>Класс наследуется от двух веток, в истоках одной деструктор виртуальный, в истоках второй нет, и мы его удаляем по указателю на ту ветку, где виртуальный. Будут ли вызваны все деструкторы? _>Например:
_>struct A { _> ~A() {} // Non-virtual. _>}; _>struct B { _> virtual ~B() {} _>}; _>struct C : public A, public B {} _>B* pc = new C; _>delete pc; // будет ли здесь вызван A::~A() ?
_>Вот так по памяти и не скажу... Надо смотреть. _>Если найду раньше вас — напишу.
Сорри, это я тупить начал.
Вопрос снят.
Считайте, что я этот пост удалил, и его тут и не было.
Здравствуйте, мыщъх, Вы писали:
_>>Отсутствие виртуального деструктора повлечет невызов деструкторов всех производных классов при удалении объекта через указатель на базовый класс. М>не совсем так. в такой ситуации компилятор может подумать: вот, блин, программист-придукрок! и таки вызовет все деструкторы. а может и не подумать. зависит от реализации. отсюда и ub.
Про это первый раз слышу. Насколько я знаю, компилятор должен генерить то, что написано, а не выдумывать несуществующие вызовы (но из того, что про такое не слышал, не следует, что это точно не так — может, и бывают... найдешь доказательство — кинь сюда)
Ну и допустим даже если неизвестно, какие базовые деструкторы вызовутся, а какие нет — то это unspecified behaviour, а под UB принято понимать undefined behaviour, хотя обе фразы в сокращенном виде выглядят как UB. Ну это так...
>> А повлечь это может что угодно, смотря что делают те самые деструкторы производных классов: утечку памяти, утечку хендлов, невыход из объекта синхронизации, ну и так далее... М>ну я имел ввиду, что если деструктор не виртуальный, то мы не можем гарантированно сказать какие десктруторы будут вызваны, а какие не будут.
Здравствуйте, Ikemefula, Вы писали:
I>Если переводчик не знает английских букв то крути не крути, он не сможет переводить в принципе.
В некоей окрестности меня есть ненулевое количество лиц 4 лет от роду, не обладающими знанием как русских, так и английских букв, но тем не менее владеющих синхронным переводом.
P.S. Вот что бывает, когда начинают натягивать дурацкие аналогии.
Здравствуйте, Ikemefula, Вы писали:
I>Да, в с++ это именно так — язык полностью осваиватеся где то через 2-3 года работы, а многие вообще никогда не освоят.
Есть подозрение, что полностью С++ осваивает где-то один из 10000, и не за 2-3 года, а за 10.
Здравствуйте, cppboris, Вы писали:
C>Здравствуйте, skeptic, Вы писали:
S>>А вот не надо потому что пытаться сесть одним местом на два стула. К тому же это вредно для индустрии. Когда один человек копает охапку безсвязных технологий не вглубь, а вширь и потом как бэ естественно считает просто своим долгом нагадить в своём резюме красивыми англицкими словечками, а хЫар естественно ведётся на колличество и красивость этих самых словечек в этих самых бумажках, то в итоге получаем что на собеседование часто попадают те кому собственно пофиг на чём писать ибо один фиг он ничего толком не знает, а работодатель зачастую вздыхает и решает мол стерпится-слюбится(да и к тому же такой с позволения сказать "специалист" кушать много не просит что играет в его пользу но не в пользу индустрии к сожалению), или же продолжает поиски кандидатов не меняя при этом технику поиска этих самых кандидатов ссылаясь на то что дескать мало спецов хороших осталось и эти поиски могут затянутся на очень долгий срок. C>Вообще говоря такая ситуация имеет место обычно не по инициативе сотрудника. А как раз работодателя. Таковы условия — такова работа. Не сделаешь ты, не сделает никто. Проект загнётся. C>Напомню, я говорю о небольших конторках в основном в провинциях. У на вот в городе, почти все такие. И не всегда есть альтернатива. C>Так что тут ситуация двоякая. Нельзя говорить о полной вине сотрудника. Честно говоря, не вижу реально рабочего выхода из подобной ситуации. Может, вы подскажите?
А что, может и подскажу.
1. Прежде всего — проект делают люди, именно люди есть показатель развития конторы. Достаточно посмотреть на текучку кадров в конторе что бы понять насколько эта контора развита. В идеале люди приходить в контору должны, а уходить нет (вариант с наручниками и батареей себя изжил и не катит). Но для начала надо повысить качество персонала уже трудоустроенного у вас. И только потом можно набирать либо профи и/или если таковые отсутствуют на рынке в момент набора — джуниоров, но с чётко выраженными горящими алым пламенем глазами (это важно), ибо нам нужны люди любящие своё дело.
2. Люди хотят есть, и хотят есть всё больше пропорционально своему развитию , поэтому срубить бабла на развитии персонала без увелечения зарплатной миски не получится — люди пойдут кушать в соседнюю забегаловку.
3. Развивать надо не только программистов, а очень важно развивать продажников, менеджеров и прочий персонал который занят поиском клиентов и реальным зарабатыванием бабла для конторы. Ибо разивая только программистов можно столкнутся с той же проблемой что и в п.2. Проектов по пальцам пересчитать, а развитые программисты уже порядком проголодались и заскучали. Побредут в соседнюю забегаловку.
4. Под развитием понимать надо не 5-дневные 10-часовые курсы с аттестацией и пышногрудыми certified trainer-ами. Знания должны получаться только добровольно, и только теми кто хочет их получить. Над теми кто не хочет должен неумолимо зависнуть топор увольнения — только по тихому, без шума и внезапно(!), ибо если такой не желающий развиваться работник заподозрит вас в чём то — то начнёт притворяться и тогда это будет та ещё головная боль. Инвестировать надо в книги, даже в маленькой конторе можно сделать библиотеку, на первое время повесив обязанности библиотекаря на какую нибудь девочку-стажёрку(но только на первое время). Проверять знания не надо посредством экзаменов — это глупо, ведёт к недовольствам и зазубриванию, а нам нужны реальные знания и реальный интерес работника, если всё сделано правильно знания дадут о себе знать в порядке растущего качества ПО и уменьшения колличества свиданий проектов с дедлайном.
В общем и целом — нет стандартного рецепта быстро дающего 100% гарантированный результат. Но надо запомнить что набирать надо только тех кому нравиться продавать/разрабатывать/проектировать/рекламировать/тестить/etc — если у человека есть реальный интерес, то и знания к нему как к магниту гвозди лепяться, и работает он по большей части не за зарплату(она как важный но всё таки побочный продукт для него), а если нет то пусть он будет хоть с 30-летним стажем и 5 дипломами о высшем образовании во лбу — он не сыграет в сторону развития конторы, ибо работает только за
з/п. Ещё раз скажу что гарантировать какой либо результат невозможно. Риск? Риск! Но это и есть работа хорошего менеджера. Управлять рисками. Иметь чутьё на них. Взвешивать их и принимать правильное решение. И так уж вышло что одни всю жизнь перестраховываются и живут чем прийдётся и как прийдётся утешая себя тем что зато они в безопасности, а другие по жизни рискуют но зато потом если повезёт мчатся на мерседесах и ухмыляются смотря сквозь тонированное стекло на тех первых которые типа в безопасности. Случай? Случай! Везение! Но везение по большей части есть результат упорного труда и правильных, обдуманных решений. Вот как то так.
Здравствуйте, IT, Вы писали:
IT>Подавляющее большинство программистов не занимаются собственным профессиональным развитием. Приходят на работу в 9:00, решают текущие задачи до 6:00 и идут домой. Сложность решаемых задач позволяет не развиваться, а самим им не надо.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, IT, Вы писали:
bnk>>>Но что движет этим "читающим" меньшинством?
IT>>Лень.
bnk>То есть, я тебя так понимаю, новые технологии и более широкий кругозор позволяют сократить трудозатраты и повысить производительность. bnk>То есть, позволяют сделать ту же задачу меньшее время. А высвободившееся время использовать для чего-то другого. bnk>Правильно?
bnk>Просто вспомнился анекдот
bnk>
bnk>Под пальмой лежит мужик и млеет. Мимо проходит другой:
bnk>— Вот ты, лежишь, бездельничаешь, а мог бы на пальму залезть, нарвать бананов. Пойти на рынок и продать.
bnk>— А зачем?
bnk>— Ну как, зачем!? На деньги с проданного купишь тележку и отвезешь на рынок намного больше!
bnk>— А зачем?..
bnk>— Да ты с проданного уже сможешь купить грузовик и возить действительно большие объемы, потом наймешь работников, а сам будешь лежать и ничего не делать!
bnk>— А я, в принципе, и так лежу и ничего не делаю?!
Э нет, не из всего можно(и нужно) выделять материальную прибыль. Для чего мужчина/женщина начинает встречаться с девушкой/мужчиной а потом жениться/выходит замуж на ней/за него? Неужто только для продолжения рода или по расчёту? Нет, нет, и ещё раз нет. В большинстве случаев это любовь. Да, да. Банально, но факт. Это потом уже через какое то время это чувство может притупиться и вместо него остаётся лишь память о светлом прошлом и обязанности перед детьми, бытовуха и другие прелести жизни в браке. Но изначально это любовь, при чём до этой любви у человека может быть много случайных и не случайных связей и всё же они рвутся когда приходит любовь. Точно так же и с читающим меньшинством — читают не для того что бы получать з/п сокращать трудозатраты и т.д а потому что это — любовь, любовь к своему делу. И проблема индустрии заключается как раз в том что на данный момент в индустрии слишком много таких вот "браков по расчёту" — когда в индустрию приходят не те люди, люди без любви к своему делу но с огромной жаждой лёгких денег, занимают чужие места, и вообще ведут себя крайне нагло, и всей толпой рубят сук на котором кроме них к тому же сидит это "читающее меньшинство". И если после того как сук окончательно сломается эти случайные люди побредут в другую индустрию (ибо пофек же чем заниматься только бабло платили бы) то "меньшинству" скорее всего прийдётся ой как туго.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, ArtemGorikov, Вы писали:
AG>>Кстати это скучный вопрос, — интереснее спросить, для чего нужен виртуальный конструктор и как сделать деструктор чисто виртуальным, какую парадигму использует auto_ptr — это если касаться плюсов. O>Не интересно задавать подобные вопросы. С 5-го раза надоедает слушать мычание с закатыванием глаз.
Странно, мне показалось наоборот- никого этим не удивить и "гвоздем" программы выступает ромбовидное наследование и "как сделать дедлок", а на закуску- паровозики с гномиками.
Здравствуйте, hrensgory, Вы писали:
H>Потому что в силу ряда причин в ИТ у начинающих необоснованно высокие H>зарплаты (резкий старт), а потолок в большинстве компаний диктуется H>экономическими ограничениями. По-хорошему вместо 50 должно быть 25-30, H>тогда 75-100 смотрится совершенно нормально.
при средней зарплате в 25 тыр по Москве?
Это не программисты много просят, это вы их труд неэффективно используете, раз даже рабочие без высшего образования получают больше.
Здравствуйте, Ikemefula, Вы писали:
J>>... и не может рассказать ни одного правила грамматики. Но зато переводит на лету, без ошибок и с учетом менталитета англичан и россиян — я за такого переводчика. Если бы я отвечал за прием переводчиков на работу, я бы взял его, а не вчерашнего студента, который наизусть знает все правила и запинается в реальной жизни. I>Если переводчик не знает английских букв то крути не крути, он не сможет переводить в принципе.
оба-на, ты не обучен устной речи?
J>>А еще есть великие музыканты не знающие нотной грамоты — вы, с переводчиком, переводите дискуссию на проигрышное для вас поле. I>Ты с переводчиком сел большую лужу и даже не заметил этого.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, ArtemGorikov, Вы писали:
AG>>Кстати это скучный вопрос, — интереснее спросить, для чего нужен виртуальный конструктор и как сделать деструктор чисто виртуальным, какую парадигму использует auto_ptr — это если касаться плюсов. O>Не интересно задавать подобные вопросы. С 5-го раза надоедает слушать мычание с закатыванием глаз.
А можно вопрос к слову, раз уж заговорили об auto_ptr?
Саттер вместе с Александреску выступают активно против auto_ptr, приравнивая к злу похуже голых указателей. Тем не менее во многих книгах уважаемых людей встречаю повсеместное использование этого умного указателя (в частности, сейчас читаю Lomow & Co "C++ FAQs" — тут любое remote ownership в классе упаковано в auto_pointer, а не в shared_pointer).
Так ли плох auto_pointer? Или верить никому нельзя, и нужно самому совершить все ошибки?
Здравствуйте, Denwer, Вы писали:
D>Как такое может быть? Что творится с людьми?
А люди просто изучили и используют boost, в частности shared_ptr. Привожу пример из книги об использовании boost.
The following example shows how to store shared pointers in a Standard Library container.
#include "boost/shared_ptr.hpp"
#include <vector>
#include <iostream>
class A {
public:
virtual void sing()=0;
protected:
virtual ~A() {};
};
class B : public A {
public:
virtual void sing() {
std::cout << "Do re mi fa so la";
}
};
boost::shared_ptr<A> createA() {
boost::shared_ptr<A> p(new B());
return p;
}
int main() {
typedef std::vector<boost::shared_ptr<A> > container_type;
typedef container_type::iterator iterator;
container_type container;
for (int i=0;i<10;++i) {
container.push_back(createA());
}
std::cout << "The choir is gathered: \n";
iterator end=container.end();
for (iterator it=container.begin();it!=end;++it) {
(*it)->sing();
}
}
The two classes, A and B, contain a single virtual member function sing. B derives publicly from A, and as you can see, the factory function createA returns a dynamically allocated instance of B wrapped in a shared_ptr<A>. In main, a std::vector containing shared_ptr<A> is filled with 10 elements, and finally sing is invoked on each element. Had we been using raw pointers as elements, the objects would need to be manually deleted. In the example, this deletion is automatic, because the reference count of each shared_ptr in the container is 1 as long as the vector is kept alive; when the vector is destroyed, the reference counters all go down to zero, and the objects are deleted. It is interesting to note that even if the destructor of A had not been declared virtual, shared_ptr would have correctly invoked the destructor of B!
собственно и не нужен получается виртуальный деструктор
Я знаю, как управлять Вселенной. И скажите, зачем же мне бежать за миллионом?!(c)
Здравствуйте, ArtemGorikov, Вы писали:
AG>Странно, мне показалось наоборот- никого этим не удивить и "гвоздем" программы выступает ромбовидное наследование и "как сделать дедлок", а на закуску- паровозики с гномиками.
Виртуальные функции и деструктор в том числе входят в базовые знания по С++
Зависит от того, что Вы называете базовыми знаниями. Если прочтение ISO стандарта... Кхм. Надо быть человеком с ОЧЕНЬ хорошей памятью, чтобы его запомнить. Обычно нюансы запоминаются и ПОНИМАЮТСЯ через некоторое количество лет практического использования. Нет, я ни коим разом не спорю с тем, что есть студенты, на третьем курсе знающие тот же C++ от и до. Но это, с моей точки обзора, скорее исключение чем правило. За свою долгую жизнь я нанял немало программистов C++, и практика показывает что с 2-3 годами опыта детали языка не знает почти никто. А вот с 10 годами — знают. Что-то вроде статистики .
и в самом деле, ДЛЯ ЧЕГО НУЖЕН ВИРТУАЛЬНЫЙ ДЕСТРУКТОР?
Если мы отнаследовались от класса с обычным деструктором, сделали экземпляр наследника, привели его указатель к родителю и затем удалили объект по этому указателю — то деструктор наследника не вызовется О_О. Соответственно, если наш героический наследник в конструкторе выделяет память а в деструкторе ее того, то его родителю всячески рекомендуется иметь виртуальный деструктор. Дабы память не потекла. Особенно актуально для интерфейсов, которые в С++ реализованы как обычные классы с множественным наследованием .
P.S. Пишу по памяти, лучше конечно уточнить в википедии
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, ArtemGorikov, Вы писали:
AG>>Странно, мне показалось наоборот- никого этим не удивить и "гвоздем" программы выступает ромбовидное наследование и "как сделать дедлок", а на закуску- паровозики с гномиками.
bnk>А это что? В гугле не ищется
Здравствуйте, мыщъх, Вы писали:
М>тогда уж — всех призводных классов. кстати, зачем нужен деструктор вообще — довольно каверзный вопрос
кстати да, в ассемблере деструкторов нет. Да и на С++ никто не мешает нам построить свою систему управления памятью и не вообще использовать деструкторы
!
