Здравствуйте, IROV.., Вы писали:
A>>>1. new может не сработать, нужно добавить, например, try/catch. К>>Лучше не try-catch (это слишком громоздко), а RAII — любой умный указатель или контейнер. IRO>Который будет врапером над try-catch?
Нет, RAII — это враппер над try-finally.
IRO>А еще сигнатура функции может принимать ссылку на указатель и творить с ним все что захочет
Ай, шайтан!
Только у нас сигнатура уже прописана, и там указатели передаются по значению.
Здравствуйте, Кодт, Вы писали:
К>Нет, RAII — это враппер над try-finally.
Это чемто концептуально отличаеться от try-catch?
всегда пологал что try-finally это синтаксический сахар
К>Ай, шайтан! К>Только у нас сигнатура уже прописана, и там указатели передаются по значению.
От , не заметил обьявление.
Здравствуйте, IROV.., Вы писали:
К>>Нет, RAII — это враппер над try-finally. IRO>Это чемто концептуально отличаеться от try-catch? IRO>всегда пологал что try-finally это синтаксический сахар IRO>
Они все — синтаксический сахар над longjmp.
Разница в том, что try-except пасёт исключения, а try-finally — пасёт любой исход.
Поэтому, если убирать мусор с помощью try-except, это будет дублирование кода или макароны
Здравствуйте, Кодт, Вы писали:
К>Разница в том, что try-except пасёт исключения, а try-finally — пасёт любой исход.
Ну я как бы в курсе дела, Док.
К>Поэтому, если убирать мусор с помощью try-except, это будет дублирование кода или макароны
Поэтому я и люблю такого рода синтаксический сахар но С++ извольте не дает такой возможности.
конечно можно воспользоваться запрещеным приемом и сворганить чтото типа вот этого try-finally
ИХМО без обоснования, изобретать подсистемы, и интерфесы по типу AGFuncCaller нет никакого смысла, в том числе и промышленных программах, и кстати понятие "промышленный дизайн" вообще осталось для меня не ясным. Для вас "промышленный дизайн", это наличие интерфейса SomeSubSystem и интерфейсов по типу AGFuncCaller?
А код у вас аккуратный, и в хорошем стиле, читается легко и приятно , комментарии ещё б были к функциям и классам в doxygen-е и было б идеально.
Здравствуйте, sergey_cheban, Вы писали:
_>Вот этот фрагмент особенно порадовал: _>
_>void GFuncCaller_NOSTL::clearBuff()
_>{
_> if(!BufferA) delete[] BufferA;// Это не защита. Если BufferA==NULL, проблем с deleteA все равно нет
_> BufferA = NULL; // просто незачем вызывать delete
_> if(!BufferB) delete[] BufferB;
_> BufferB = NULL;
_> gBufferSize = 0;
_>};
_>
_>У Вас действительно есть свой стиль написания кода. Вы только с названием стиля ошиблись: это не Industrial, а Trash.
Блин... вызов delete как раз только при NULL... Ляп, однако. Конструкция "если указатель нулл, то сделать что-то" в пальцы въелась, однако...
Хотел напомнить, что удаление на указателе с NULL — НЕ вызывает exception, а перехват исключений можно делать не на атомарном уровне...
Но удивлен, что супер-пупер спецы из доктора веба нашли время залезть, да скачать... Вы же говорили, что код такого ничтожества, как я, вас не интересует и задание, которое я написал для другой конторы, нефиг вам присылать?
Господин гуру, а своим кодом нас, сирых и убогих недоучек, вы не могли бы порадовать? Понятное дело, баловством каким вашим собственным, а не кодом под копирайтом — да только не задачки мелкие, которые тяп-ляп да на скорую руку, а что-нибудь хотя бы отдаленно похожее на то, как вы крупные приложения дизайните... Показали бы класс. А то все критика да критика... Так критиковать чужой код — конечно, оно полегче будет, чем свой написать. Вы вообще хоть что-нибудь пишете?
А то мы, сирые да убогие, до сих пор почитаем всяких там Крэгов Ларманов да Мартинсов со всякими "бандами четырех" и т д — а ведь пишем-то всякий там трэш поганый... Ну а вы, такой новатор и знаток — ничего своего не показываете, критиковать вас не за что.
Разве что на пресловутом собеседовании, когда я вам объяснял архитектуру приложения, которое вычищал от ошибок на предыдущей работе — ляпнули,
что АСИНХРОННУЮ обработку АСИНХРОННЫХ запросов из МНОЖЕСТВЕННЫХ источников, причем с несовпадением порядка ответов с порядком запросов,
лучше делать в один поток... Дескать, процессор на сервак современный — и вперед... Причем объяснять, вам же, что вы можете иметь в виду, пришлось мне же, рисуя примитивную схему на бумаге, так как названную мной комбинацию шаблонов вы "не расслышали".
Кстати, в ваших словах про локаль — одна ошибка и, что для вас типично, масса неопределенности. Раз такие крутые — попробуйте выяснить сами.
Из вашего письма я сделал два вывода:
1. Я был абсолютно прав в своих оценках. Себя перечитайте... "трэш"...
2. Приход даже на такое собеседование — полезен. Для работодателя — вы добрались-таки хотя бы до википедии, чтобы взглянуть на выдумки ретроградов.
Еще ограничения и перечень проблем посмотрите — и вопрос "почему так не делают, хотя теоретически возможно" с асинхронной обработкой прояснится еще больше. К тому же вы отслеживаете сообщения на этой ветке — значит, что-то полезное надеетесь углядеть. Ну и по мелочам — к примеру, не задумывались, что конструктор исключений с о строкой в параметре — это "майкрософт специфик".
Для кандидата — не побывай я у вас, или веди вы себя прилично, не полез бы в интернет, чтобы поковыряться в вопросах, которые я посчитал откровенно дурными. Не нашел бы эту статью. И не увидел бы упоминания про "Эффективное использование STL", не прочитал, наконец, эту книгу и не добрался бы и до Александреску.
Здравствуйте, TarasKo, Вы писали:
TK>ИХМО без обоснования, изобретать подсистемы, и интерфесы по типу AGFuncCaller нет никакого смысла, в том числе и промышленных программах, и кстати понятие "промышленный дизайн" вообще осталось для меня не ясным. Для вас "промышленный дизайн", это наличие интерфейса SomeSubSystem и интерфейсов по типу AGFuncCaller?
Вы правы, конечно. ВЕСЬ этот код — одно сплошное баловство. Написанное просто так, без веской причины. Дизайн создается под конкретную цель.
Здесь — вообще никакой цели. Говоря о "промышленном дизайне" всего-навсего имел в виду, что есть и подходы, целесообразные для небольших задач (которые можно написать в одиночку за разумное время), либо "одноразовых". А то, что для мелких задач является избыточно сложным, становится экономически выгодным на крупных задачах, которые живут долго — и постоянно модифицируются, да притом и разными людьми.
TK>А код у вас аккуратный, и в хорошем стиле, читается легко и приятно , комментарии ещё б были к функциям и классам в doxygen-е и было б идеально.
На это меня уже не хватило .
Здравствуйте, sergey_cheban, Вы писали:
_>Здравствуйте, Константин.
KC>>В общем, побывал я в DrWeb на собеседовании и даю правильный с их точки зрения ответ: KC>>По первому заданию: _>Я рад, что обсуждение недостатков Вашего первоначального ответа пошло Вам на пользу. И всё же: _>1. Хочу предостеречь от использования &a[0] без проверки на наличие в векторе хоть каких-то данных. Если мы не предупредили Вас об этой проблеме на собеседовании, это не значит, что её не существует.
Этот пункт вашей любезной критики, о глубокоуважаемый эксперт, тоже заслуживает незначительных сомнений со стороны недостойного меня.
Позвольте полюбопытствовать: а в "докторе вебе" принято КАЖДЫЙ подобный вызов просто на всякий случай заворачивать в контроль передаваемых параметров? Даже несмотря на то, что обязанность вызывающей стороны — предоставить корректные параметры вызываемой функции? А потом, при изменении потребностей вызываемой функции в минимальном размере буфера, делать изменения по всему тексту? Понимаю, что древний принцип распределения полномочий (его вариант в ООД зовется "Information Expert") уже признан ретроградным, и не с моим скудоумием судить о передовых подходах, но все же: функция g обязана знать свои минимальные потребности и сама проверять входные параметры. Для этого ей n и передается. Если же ей передано n, а размещено меньше, так как программ без ошибок не бывает вообще... Я так понимаю, что процессы многоуровневого тестирования тоже устарели и по вашим расчетам все-таки гораздо дешевле встраивать проверки вообще везде, где только можно. И, кстати, код, который вы забыли процитировать, переоценив желание читателей скачивать файлы и разбираться в них:
void g(char* a, char* b, size_t n )
{
// Функция на C.
// Разместить что-нибудь в буферы для использования
// вызывающей функцией - традиционный способ
// Для контроля над правильностью размещения
// используется n. В данном случае - строка либо образается(но 0 не ставится),
// либо дополняется нулями
if(!a || !b || !n)
return; // на самом деле нормально написанная функция на C должна возвращать
// именованую константу,
strncpy(a, "one two three",n);
a[n-1]='\0'; //
strncpy(b, "three two one",n);
b[n-1]='\0'; //
// сделать что-нибудь еще
printf("\n ===== func g said: Hello, I am C-styled legacy function . =============");
printf("\n ===== func g said: Under my responsibility is not only placing something to buffers. =====");
printf("\n ====== func g said: I am also says: 'Hello, word!' ===================");
return;
};
В общем, о дорогой Гуру, ко всем вашим замечаниям можно прицепиться. С учетом Вашего тона Вам следовало бы предпринять некоторые меры, чтобы о Вас не говорили: "Чукча не Писатель, чукча КРИТИК". КРИТИК И ПИСАТЕЛЬ — разные профессии. ВЫ ТОЛЬКО КРИТИК? Еще раз повторюсь: вы так многое видите в ЧУЖОМ коде и в ЧУЖИХ подходах и решениях. Покажите нам, КАК ВЫ САМИ пишете серьезные приложения — отнюдь не тексты под копирайтом,
о нет! И никто вас не просит выложить нечто, что требует больше нескольких часов работы. Но хочется увидеть нечто такое, что позволит судить о Вашем подходе к разработке КРУПНЫХ комплексов, которые потом в процессе КОЛЛЕКТИВНОЙ разработки будут дописываться и расширяться, модифицироваться и т д — очень-очень долго. Конечно, эти подходы сильно отличаются от того, что пишется на олимпиадах или для себя. Или нет? Пожалуйста, покажите нам ВАШЕ ВЕРНОЕ "КАК НАДО" конкретно, а не расплывчато и намеками, оставляя место для фантазий . Не стоит просто указывать на массу "КАК НЕ НАДО", если вы не только критик. Дайте же нам идеал, к которому нам надлежит стремиться!
Вы же сами критики не боитесь?
Советую забить У меня тоже бывали случаи, когда после собеседования хотелось кричать и махать кулаками, мне казалось что со мной поступили не справедливо, я тоже писал на рсдн например здесь http://www.rsdn.ru/forum/philosophy/2971148.aspx
Теперь я по другому к этому отношусь. Конечно собеседующие могут быть не идеальны, но эта та часть мира которую мне не изменить. Зато я могу изменить себя. Могу читать больше книжек, могу учиться разговаривать по другому, так что бы не возникало желания меня гнобить Вспоминая то собеседование, могу сказать что я был очень самоуверен, вел себя соответствующе, быстро и слишком подробно ответил на вводные вопросы про с++, мне иногда казалось, что собеседующий меня не понимает. Видимо этим его разозлил
Собеседование это ж не только проверка на знание, но и проверка насколько я коммуникабелен. Если так получилось что за время собеседование я разозлил интервьюера, то это тоже повод задуматься. Меня не возьмут на работу даже если я буду ВСЁ знать, ведь как потом со мной работать.
Вообщем я из того случая надеюсь извлёк свои уроки Вам сооветую сделать тоже самое и не на кого не злится
Здравствуйте, amberovsky, Вы писали:
A>При попытке устроится в одну фирму прислали "удалённое" тестовое задание.
Раз уж это задание попало на RSDN и стало предметом обсуждения, позвольте несколько комментариев от автора.
1. Целью этого задания является предварительный отсев кандидатов. Если кандидат нормально ответил на вопросы, мы приглашаем его на собеседование. Как показывает практика, на этом этапе отсеивается примерно половина кандидатов, что серьёзно экономит наше время.
2. Основным требованием к заданию является простота его выполнения (для тех кандидатов, которые нам подходят). Сложные задания отпугивают кандидатов, а нам это не нужно.
3. Никаких "единственно правильных ответов" не существует. Ответы рассматривают разработчики, а не отдел кадров. На этом этапе мы готовы принять любой вариант, который решает больше проблем, чем создаёт.
4. Мы тоже иногда ошибаемся, причём при наличии сомнений предпочитаем отказать кандидату. В конце концов, каждый ошибочно принятый на работу человек обходится нам в несколько десятков тысяч рублей чистого убытка, а каждый ошибочно отвергнутый — найдёт себе применение где-нибудь в другом месте.
5. Если кандидат в процессе чтения этой ветки узнаёт много нового и интересного для себя — это верный признак того, что ему ещё есть чему поучиться до того, как он сможет претендовать на работу у нас.
Здравствуйте, March_rabbit, Вы писали:
M_>Здравствуйте, amberovsky, Вы писали:
A>>Я ответил так: A>>1. new может не сработать, нужно добавить, например, try/catch. M_>Думаю, чисто теоретически это все правильно. Но на практике я бы не сильно заморачивался спецзащитой. Ибо нехватка памяти — это конец. Поймаешь здесь — стрельнет в другом месте (где-нить в stdlib).
M_>За 10 лет программерства ни разу не столкнулся с нехваткой памяти под программу на i386. Один раз сделал утечку, система (Linux) умерла в муках, но не призналась.
Это не так. Есть ситуации когда ловля bad_alloc спасает ситуацию.
Например при попытке выделить огромный объем памяти ее может не хватить — не рушить же из-за этого программу. Можно поймать bad_alloc и например попробовать выделить поменьше.
Если программа работает в критичном окружении (сервер, обрабатывающий тысячи запросов), на очередную операцию может запросто не хватить ресурсов. Рушить сервер в данном случе в корне неверно — нужно наоборот предпринять усилия спасти его, например перестать принимать запросы пока не освободиться память.
На практике тоже не сталкивался, но генерил такую ситуацию (Vista 32 bit, 3 Gb RAM) — ислючение отработало, винда выдержала.
Здравствуйте, KhConstantine, Вы писали:
KC>Блин... вызов delete как раз только при NULL... Ляп, однако. Конструкция "если указатель нулл, то сделать что-то" в пальцы въелась, однако...
И таких ляпов у Вас — 100% осмысленного кода. Вот ещё один:
Чем кончится вызов oSubSystem.execute(NULL) — посмотрите сами.
А вот другой: класс SomeSubSystem имеет виртуальные функции, но при этом не имеет ни предков, ни наследников. Какая муза вас посетила и почему она ушла раньше времени — загадка.
KC> Хотел напомнить, что удаление на указателе с NULL — НЕ вызывает exception, а перехват исключений можно делать не на атомарном уровне... Кому Вы хотели это напомнить? Мне? Спасибо, я уже в курсе.
KC>Но удивлен, что супер-пупер спецы из доктора веба нашли время залезть, да скачать... Вы же говорили, что код такого ничтожества, как я, вас не интересует и задание, которое я написал для другой конторы, нефиг вам присылать?
Но ведь сейчас речь идёт о другом коде — о проекте, созданном 1 мая (это дата stdafx.cpp. Cобеседование, напомню, состоялось 29 апреля), в котором упоминается торговая марка моей компании. Как тут удержаться от любопытства?
KC>Господин гуру, а своим кодом нас, сирых и убогих недоучек, вы не могли бы порадовать?
Вы меня точно ни с кем не путаете? У меня нет больших объёмов собственного кода под свободными лицензиями. Моё участие в open source разработке ограничивается вот этим скромным вкладом: http://groups.google.com/group/fardev/browse_thread/thread/94ead2b8004314e4?pli=1
KC>Вы вообще хоть что-нибудь пишете?
Да, пишу. Нет, не покажу.
KC>Разве что на пресловутом собеседовании, когда я вам объяснял архитектуру приложения, которое вычищал от ошибок на предыдущей работе — ляпнули, KC>что АСИНХРОННУЮ обработку АСИНХРОННЫХ запросов из МНОЖЕСТВЕННЫХ источников, причем с несовпадением порядка ответов с порядком запросов, KC>лучше делать в один поток...
Уж не знаю, правильно ли я понял Вас, но Вы меня в тот момент точно поняли неправильно. По сути, в ответ на Ваше утверждение "поскольку у нас есть много клиентов, нам необходимо много потоков" я предложил Вам однопоточный вариант. Преимущества у этого варианта есть, недостатки тоже, и разговор мог бы получиться интересным. Но — не судьба.
KC>Кстати, в ваших словах про локаль — одна ошибка и, что для вас типично, масса неопределенности. Раз такие крутые — попробуйте выяснить сами.
Угу, есть. Тогда тем более не понимаю, зачем Вы приписали нам свои заслуги.
Здравствуйте, alxn1, Вы писали:
A>Офигеть. Сколько негатива и неуважения. Даже "Вы" выглядит издевкой.
"Вы" — это не издёвка, а вежливость. Очень полезная штука: она позволяет более-менее сносно общаться людям в конфликтной ситуации. А негатив и неуважение — всё-таки лучше неискренности в стиле "Вы замечательно ответили на все наши вопросы и очень нам понравились, но работу поищите в другом месте".
A>Ждем и правда вашего кода.
Зачем? В данном случае оценка моей квалификации зависит не от моего умения писать код, а от того, правильно ли я оценил кандидата. Если Вы считаете, что я ошибся — пожалуйста, берите его себе.
Надеюсь, Вы чувствуете границу между защитой чести и достоинства и самоутверждением. Я эту границу переходить не хочу.
Здравствуйте, KhConstantine, Вы писали:
KC> Покажите нам, КАК ВЫ САМИ пишете серьезные приложения — отнюдь не тексты под копирайтом, KC>о нет! И никто вас не просит выложить нечто, что требует больше нескольких часов работы.
Вы предлагаете мне быстренько, на коленке, за пару часов написать "серьёзное приложение"?
Или Вы предлагаете написать что-нибудь простенькое, но использовать при этом избыточно "тяжёлый" подход?
KC>Дайте же нам идеал, к которому нам надлежит стремиться!
Отстаньте, нет у меня этого идеала. И нимба вокруг головы — тоже нет.
KC> Вы же сами критики не боитесь?
Вам угодно считать меня плохим программистом? Ради бога. Главное — не ставьте мои копирайты на свой код и воздержитесь от описаний моего мнения.
Вам угодно заняться фаллометрией на форуме? С этим — не ко мне.
Здравствуйте, sergey_cheban, Вы писали:
_>Здравствуйте, amberovsky, Вы писали:
A>>При попытке устроится в одну фирму прислали "удалённое" тестовое задание. _>Раз уж это задание попало на RSDN и стало предметом обсуждения, позвольте несколько комментариев от автора.
_>1. Целью этого задания является предварительный отсев кандидатов. Если кандидат нормально ответил на вопросы, мы приглашаем его на собеседование. Как показывает практика, на этом этапе отсеивается примерно половина кандидатов, что серьёзно экономит наше время. _>2. Основным требованием к заданию является простота его выполнения (для тех кандидатов, которые нам подходят). Сложные задания отпугивают кандидатов, а нам это не нужно. _>3. Никаких "единственно правильных ответов" не существует. Ответы рассматривают разработчики, а не отдел кадров. На этом этапе мы готовы принять любой вариант, который решает больше проблем, чем создаёт. _>4. Мы тоже иногда ошибаемся, причём при наличии сомнений предпочитаем отказать кандидату. В конце концов, каждый ошибочно принятый на работу человек обходится нам в несколько десятков тысяч рублей чистого убытка, а каждый ошибочно отвергнутый — найдёт себе применение где-нибудь в другом месте. _>5. Если кандидат в процессе чтения этой ветки узнаёт много нового и интересного для себя — это верный признак того, что ему ещё есть чему поучиться до того, как он сможет претендовать на работу у нас.
>> несколько десятков тысяч рублей чистого убытка
Понятен стандартный уровень ваших зарплат. >> до того, как он сможет претендовать на работу у нас
Да, каждый сам устанавливает планку. И компании уровня "несколько десятков тысяч рублей"/брэнд из разряда "а разве они все еще существуют?" — тоже.
Ну что же, из Ваших прочих сообщений видно, что лично Ваш код проанализировать не выйдет. Жаль.Везде можно найти нечто интересное и поучительное.
В частности, здесь и сейчас даю наводку на популярные книги Эрика Берна, основателя транзакционного анализа: "Игры, в которые играют люди" и "Люди, в которые играют в игры". Форум — программистский, наводка — на работы по психологии, полезные всем, чья существенная часть работы связана с взаимодействием с другими людьми.
С другой стороны, есть такая крайне полезная техника: "инспекция кода/дизайна/документа равными". Двойной эффект: огромный плюс в плане передачи знаний + очень простой и очень дешевый, но очень эффективный способ повышения качества кода. Соответственно и производительности труда в целом (и программисты быстрее и полнее изучают систему/быстрее работают за счет снижения затрат на собственные исследования кода, и раннее обнаружение ошибок означает снижение затрат за счет сокращения цикла код->тестирование-> CR -> анализ -> исправление ). Практикуется Моторолой с ее "шесть сигм" и массой других брэндов. Заключается в обязательном объяснении разработчиком своих исправлений группе коллег. Но требует соблюдения определенных норм общения — в частности, обязательно исключительно общение в благожелательно-нейтральном/безэмоциональном стиле ("взрослый->взрослый", определение проблемы/сбор информации/поиск решения). Иначе — конфликты, и исполнители думают не столько о работе, сколько прокручивают в голове разные внутренние диалоги.
В адаптированном виде описание применения транзакционного анализа нередко включается в ученики по управлению проектами, team building, etc
В соответствии с этой терминологией: Практически все транзакции идут у Вас с позиции "родитель критикующий". Позиция известна, как наиболее конфликтная и наименее продуктивная. Человек, общающийся с этой позиции, в своем восприятии транслирует все ответные транзакции, к какому бы типу они ни принадлежали в действительности, исключительно в два типа: "Ребенок послушный->Родитель критикующий" и "ребенок непослушный-> родитель критикующий". Второй тип вызывает отторжение. Так, данный абзац оформлен в нейтральном стиле, а какие чувства он вызывает у вас? Замечу, что на собеседовании вы тоже получали с моей стороны транзакции "взрослый->взрослый".
Конфликтная природа позиции "Родитель критикующий" вызвана прежде всего тем, что для человека в позиции "родитель критикующий" единственно приемлемой ответной транзакцией является транзакция с позиции "ребенок послушный". Соответственно собеседнику навязывается позиция "ребенок". Поскольку для полноценного взрослого человека, без заниженной самооценки, позиция "ребенок послушный" является крайне невыгодной, идет отторжение невыгодного шаблона поведения на инстинктивном уровне. Если же по каким-либо причинам человек вынужден следовать шаблону "ребенок послушный" долгое время, рискует в этой позиции и застрять, заполучив в итоге заниженную самооценку. Что крайне вредно для продуктивности — человек слишком боится ошибиться, следует принципу не ошибается лишь тот, кто ничего не делает.
В общем, при коллективной работе оптимальным признается исключительно "взрослый->взрослый", ограниченно допустимым (если собеседник сам переключился в позицию "ребенок", что типично при обращении к человеку с более высоким рангом) — "родитель поддерживающий/покровительствующий".
Что интересно: человек, для которого типична позиция "родитель критикующий", зачастую всеми силами избегает что-либо делать САМ из-за инстинктивного страха совершить ошибку — слишком привык к своей позиции и слишком хорошо знает, что чувствуют его собеседники. Тем более, что этот шаблон поведения зачастую является результатом обезъянничанья со стороны человека, для которого ранее был типичен шаблон "ребенок послушный".
Если в вашей компании большая текучка и проблема с подбором кадров — возможно, это небольшое эссе укажет на одну из причин. Возможно, в схеме "может/ему разрешено/хочет" требование следовать шаблону "послушный ребенок" оказалось в "может"
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, TarasKo, Вы писали:
TK>Советую забить У меня тоже бывали случаи, когда после собеседования хотелось кричать и махать кулаками, мне казалось что со мной поступили не справедливо, я тоже писал на рсдн например здесь TK>http://www.rsdn.ru/forum/philosophy/2971148.aspx
TK>Теперь я по другому к этому отношусь. Конечно собеседующие могут быть не идеальны, но эта та часть мира которую мне не изменить. Зато я могу изменить себя. Могу читать больше книжек, могу учиться разговаривать по другому, так что бы не возникало желания меня гнобить Вспоминая то собеседование, могу сказать что я был очень самоуверен, вел себя соответствующе, быстро и слишком подробно ответил на вводные вопросы про с++, мне иногда казалось, что собеседующий меня не понимает. Видимо этим его разозлил
TK>Собеседование это ж не только проверка на знание, но и проверка насколько я коммуникабелен. Если так получилось что за время собеседование я разозлил интервьюера, то это тоже повод задуматься. Меня не возьмут на работу даже если я буду ВСЁ знать, ведь как потом со мной работать.
TK>Вообщем я из того случая надеюсь извлёк свои уроки Вам сооветую сделать тоже самое и не на кого не злится
У меня с коммуникабельностью все в порядке, спасибо. Выводы тоже давно сделал. В частности, пришел к выводу, что если на собеседовании возможные коллеги из числа "равных" не могут вытерпеть отношение "равный к равному" — потом тем более не смогут. Думаю, что ставить себя в позу "послушный мальчик" на собеседовании имеет смысл только в особых случаях.
А вот предела совершенству в профессиональной сфере — действительно нет.
Перекуём баги на фичи!
, не заметил обьявление.
, комментарии ещё б были к функциям и классам в doxygen-е и было б идеально. 
.
):
