ansi wrote: > > K>Инкапсуляция: ... > K>Наследование: ... > K>Полиморфизм: ... > > Что-то мне подсказывает, что у товарища Сметанина мы бы интервью не прошли
Если бы задавали такие вопросы, то да. Для студента это вопросы,
насколько хорошо зазубрил формулировки из лекций, для профи
среднего уровня — повод поехидничать над терминологией,
для профи высокого класса — признак невменяемости рекрутера.
На списки-деревья эффект не распространяется, списки да
алгоритмы относятся к простым базовым концепциям, достойным
уважения, а вот ООП — к псевдонауке. Есть ряд базовых идей
(публичный интерфейс + запрет других методов взаимодействия,
выделение групп общих признаков объектов в виде классов
объектор, повторение этой операции рекурсивно уже к самим
классам объектов, плюс синтаксический сахар для возможности
работать с данными свойствами объектов общим образом),
безусловно полезных, и столь же безусловно требующих
большой аккуратности в обращении, а есть куча гнилой
демагогии сверху.
Здравствуйте, DEMON HOOD, Вы писали:
eaa>>А если дурак? DH>то увольняется по истечении исп. срока
Продержать человека на испытательном сроке это не оправдано дорого. Вот простая арифметика. Нам нужен один человек. Если исходить из статистики людей которые пришли на собеседование (даже не пришли, а успешно прошли первое собеседование), то по оптимистичным прогнозам, только десятый человек останеться работать. Значит, для того что бы таки взять одного. нам прийдёться нанять 10, и потом 9 уволить по окончании испытательного срока (я говорю в среднем, если прийдётся уволить 4 то чудненько, но я в это не верю). Даже если отбросить стоимость офиса и техники. Мы будем должны оплатить 10 месячных зарплат этим людям. Из которых останеться один. Кроме того, как минимум один ведущий будет постоянно занят этим кагалом, то есть и его зарплата уйдёт в некуда. При таких условиях наём человека становиться очень дорогим.
MSS>>- надо понимать, что опыт работы и качество мозгов — вещи разные.
SR>Безусловно. Помимо качества мозгов (знаний и способности решать проблемы) есть еще личностные качества, что также немаловажно. И хотя собеседование выявляет многое, оно не гарантирует того, что человек будет успешно справляться, особенно когда нельзя опереться на предыдущий опыт.
На самом деле многие гиганские транснациональные компании типа Проктера и Гэмбла так набирают народ. Преимущество — приученность людей сызмальства к их корпоративной культуре, и ослабление необходимости конкурировать на рынке состоявшихся спецов (больше шансов повысить кого-то из своих и закрыть вакансию).
SR>Речь, все-таки, не о том, что студентам можно платить ниже рыночной стоимости, а о том, что рыночная стоимость человека без опыта невысока.
По-всякому можно, но надо всегда понимать последствия той или иной политики.
>Но она может быстро вырасти и за этим нужно внимательно следить чтобы не остаться в дураках. Недоплачивать также невыгодно как переплачивать.
По-разному невыгодно . От недоплаты две проблемы а) текучесть б) сложность набора персонала, причем пункт б) намного более ощутим. Кстати, можно удержать человека, который уходит исключительно по причине повышения денег. Столько же денег дать — и все. Естественно, это подразумевает, что, например, личные отношения с руководством у него нормальные.
И еще одна сторона дела. Как мне кажется, работодатель всегда оказывает на сотрудника прессинг. Который состоит из многих вещей — требования к количеству работы, требования к срокам, жесткость корпоративной культуры, жесткость денежных штрафов (если они есть), личная "тяжесть" шефа, и так далее. Я слышал даже такое утверждение (от специалистов уровня 1200 в месяц) — "неограниченное использование Интернета на рабочем месте равняется плюс 100 баксов к зарплате". Некоторые даже с директором такие разговоры подымали, после того, как он Интернет ограничил на столах. Люди всерьез восприняли это как уменьшение компенсационного пакета .
И тут важно не переборщить. Если затянуть все эти параметры сильно — то их общая сумма превысит некий порог почти для всех, и пойдет текучесть. Можно смягчить дело мазохистской ориентацией конторы по типу "а мы тут зато Настоящим занимаемся, а Настоящее без страданий не бывает" — но это не решает всех проблем.
Так что, если нужно затянуть гайки в чем-то одном — то нужно следить, чтобы это компенсировалось в другом.
И дальше — мы подошли к финальному выводу — если контора осознанно ориентируется на недоплату, то нужно расслаблять остальное. Т.е. никакого авторитарного стиля руководства с хамством, доверие людям, нет ограничений на Интернет со столов ну и так далее. Кого-то это устроит, и снизит количество попыток ухода.
SR>К тому же непонятно, что заставляет вас считать, что на 1200 лохов набежит меньше Может статься совсем наоборот. Пролема может решаться эффективным скринигом.
Скрининг и делался, чтением пачки резюмешек вот после такого скрининга на 1200 приходили в массе своей адекватные люди, а на 600 — все равно неадекватные.
SR>Этот подход применим (и вполне оправдан) к опытным разработчикам, доказавшим свою эффективность на практике. Но как раз в случае стажера никаких гарантий, как правило, нет. Даже в случае более высокой зарплаты.
Конечно. Переплата стажерам, собственно, вообще не дает ничего, кроме покупки их лойяльности.
Здравствуйте, ansi, Вы писали:
K>>Инкапсуляция: ... K>>Наследование: ... K>>Полиморфизм: ...
A>Что-то мне подсказывает, что у товарища Сметанина мы бы интервью не прошли
На стажёра — не прошли бы точно!
Кхм. Я придерживаюсь убеждения, что кто ясно мыслит, тот ясно излагает. Так что если человек не может ясно сформулировать свои пусть даже туманные остаточные знания — у меня возникают подозрения, что этот человек нормально вообще ничего сформулировать не в состоянии. Ничего не могу с собой поделать!!!
А так, в данных "определениях", например, инкапсуляции — на мой взгляд отчётливо сквозит опыт работы с COM (а вот с ООП они не имеют вообще ничего общего)... Самое забавное, что общепринятых строго формальных определений просто нет. Так что, требуя с человека эти определения, получаешь скорее именно представление о том, сможешь ли ты с ним сработаться, есть ли у вас точки пересечения. Судя по высказываниям kittown — я с таким человеком в одной команде работать бы не смог. Это не в коей мере не оценивая профессионализма — просто по человечески. Принципиально разный взягляд на базовые вещи. Мы бы наверняка просто подрались через 15 минут любого обсуждения.
Приведу пример:
Инкапсуляция: выборочное закрытие доступа к тем или иным частям
объекта. Открытым оставлять рекомендуется лишь некий набор методов,
составляющий официальный интерфейс. Еще рекомендуется делать умное
лицо и говорить, что скрыты детали реализации, как будто они не
проявятся через, скажем, временные характеристики работы, объем
используемой памяти, и характер изменения данных величин.
Мой вариант определения такой: инкапсуляция — объединение в одной сущности данных и механизмов работы с ними. Всё! Дальше — пояснение: таким образом обеспечивается целостность данных в том смысле, что изменяться они будут только специально предназначенными для этого механизмами.
Я хочу подчеркнуть, что инкапслуяция — это термин относящийся отнюдь не только к ООП. Например, при модульном подходе инкапсуляция данных и механизмов обработки производится в модули (вместо классов в ООП). В некотором смысле можно даже говорить о инкапсуляции локальных переменных внутри процедур!
И вот, если человек не понимает, что термин "инкапсуляция" — это не что-то, порождённое ООП (а наоборот, просто одна из основных составляющих ООП) — мне это говорит о том, что "взгляд на жизнь" и базовые понятия у нас сильно отличаются.
Хмм... Интересно, насколько ясно излагаю я свои мысли? На всякий случай пример инкапсуляции в том смысле, в каком я понимаю термин: СУБД инкапсулируют в себе данные (собственно, БД) и средства доступа к ним (собственно, СУ). Ни один программист в здравом уме не полезет из своей программы напрямую менять файл, в котором СУБД хранит данные!
А что касается "скрыты детали реализации" — это, на мой взгляд вообще не имеет отношения к инкапсуляции!
kittown, приношу извинения. Виноват, не дочитал пост:
На самом деле, это все старая добрая концепция черного ящика, ничем
ООП не обязанная, зато специальное имя подчеркивает ее применимость
по отношению к классам и имеет высокое воспитательное значение.
Понимание того, о чём я писал, как раз имеет место. Так что вот это я зря написал:
S>И вот, если человек не понимает, что термин "инкапсуляция" — это не что-то, порождённое ООП (а наоборот, просто одна из основных составляющих ООП) — мне это говорит о том, что "взгляд на жизнь" и базовые понятия у нас сильно отличаются.
На всякий случай, добавлю. Про ясность изложения — это было вообще сказано просто для пояснения позици (зачем я всё равно буду спрашивать определения).
Smetanin wrote: > > Здравствуйте, kittown, Вы писали: > > K>... а вот ООП — к псевдонауке.... > K>... а есть куча гнилой демагогии сверху.
Классно заквотили.
> Вот с этим — в корне не согласен.
С чем конкретно ? Возьмите свое представление
об ООП, уберите из него наследование и
создание интерейсов (полиформизм и сокрытие
реализации относится к механизму организации
интерфейса), уберите специфику используемых
вами языков программирования, что у вас
тогда останется, помимо демагогии ?
Smetanin wrote: > > сработаться, есть ли у вас точки пересечения. Судя по высказываниям > kittown — я с таким человеком в одной команде работать бы не смог. Это > не в коей мере не оценивая профессионализма — просто по человечески. > Принципиально разный взягляд на базовые вещи. Мы бы наверняка просто > подрались через 15 минут любого обсуждения.
Вряд ли. Но судя по тексту, рассинхронизация проявилась бы где-нибудь в
другом месте. Не так сильноЮ как на текущем месте работы, но все же.
Пример с вопросом на собеседовании. Типичный сценарий:
Позиция интервьюера: задать тестовый вопрос, проверить
соответствие ответа своему.
Моя позиция: традиционный ответ бесполезен — его и так
все знают, но раз есть повод, можно упомянуть не всегда
заметные узкие места.
Позиция интервьюера: че сказал, зачем сказал...
Совсем плохо, когда интервьюер, предполагаемый менеджер,
фанатеет от используемой технологии. Не к добру это.
Другой пример, ближе к практике.
Перец-начальник: вот проблема, вот так все обстоит, ...
Я (прерывая): не совсем так, вот то не так, и это
не так. Поэтому все сделанные на основе этого
выводы — в корзину, и думать надо заново.
Через полгода от него же узнаю, что произвел впечатление
невменяемого — "начал обсуждать несвязанную тему", которую
упоя. Хотя потом эта тема аукнулась ровно указанным образом.
И куда это списывать ? В оверквалифи ? Так у того кадра
успешность собственных проектов в среднем выше. К неспособности
выразить мысли ? Так со временем начинают использоваться мало
отличающиеся от моих формулировки.
Ладно, что-то я увлекся... Все бы хорошо, но деградируешь на
таком киселе с крейсерской скоростью.
> Мой вариант определения такой: инкапсуляция — объединение в одной > сущности данных и механизмов работы с ними. Всё!
Это как раз и есть та самая общая очевидная часть.
Этот момент не был четко описан, поскольку выпал
из "оперативной памяти", к тому же именно ваша
формулировка (интерфейс+данные) подвергалась
сильной критике в то время, когда я все это изучал.
Вот за такие разногласия в терминологии и ее
определениях "теоретическое" ООП и не люблю.
Все равно в конце для ясности приходится
ссылаться на черный ящик, на метафору станка
и деталей, или еще на что-нибудь.
Здравствуйте, Anatolix, Вы писали:
A>Помоему у тебя галлюцинации. Если ты перечитаешь POST, то ты не увидишь, что в отношении себя я там использую слово слово "наслышан на уровне статей в компьютерре". А слово "хорошо знают" использую по отношению к людям которые пишут драйвера, которые я не пишу. Я пишу многопоточные сервера.
Если ты перечитаешь _мой_ пост, то слов "хорошо знать" не увидишь. Просто потому что их там _нет_.
Перечитал?
Так у кого галлюцинации (1)?
ggg>> Однако анти-шаблон "double checked locking" с этой шиной не связан. A>Непосредсвенно не связан. Согласен, здесь я расширил область до апаратной архитектуры.
Что именно ты расширил? Шину PCI? Платформу IA32? _Что_ ты хочешь сказать-то вот этой своей странной фразой?
Может ты честно признаешь, что пытался продемонстировать своё базовое "знание" шины PCI псевдоумными
фразами, которые, однако, к PCI не имеют никакого отношения (и ты сам фактически признал это уже во втором сообщении на данную тему)?
A>Appropriate use of synchronization and a fencing operation (see “The fence Instructions” later in this A>chapter) must be performed for producer-consumer usage models. Fencing ensures that all system agents A>have global visibility of the stored data; for instance, failure to fence may result in a written cache A>line staying within a processor... ggg>> Во-вторых, такие инструкции есть и на IA32 (mfence, lfence, sfence). A>Вот именно на них "не имеющих никакого отношения к кэшу" и ведет ссылка see “The fence Instructions”
См ниже.
ggg>> К "синхронизированной памяти" это, вообще говоря, не имеет отношения. A>Имеет непосредственное, именно такая синхронизация кэшей вместе с уcловием write-thru прописывания сквозь кэш дает синхронизированность памяти.
Для "Синхронизация кэшей" (то есть для сброса грязной строки кэша в память) есть инструкция clflush. Нигде не сказано, что mfence/sfence/lfence _инициирует_ синхронизацию кэша с памятью (в том числе и в твоей цитате). mfence/sfence/lfence только _ждут_ когда завершатся _уже начатые_ операции с памятью. fence instruction не заменяют clflush, а дополняют её (см. пример про clflush в том же документе, сразу после главы "The fence instructions").
Но самое главное, что для того, чтобы один процессор увидел изменение строки кэша в другом процессоре, не нужно сбрасывать эту строку в память. Из 10.2 "Caching Terminology" в "IA32 Architecture Software Developer's Manual. Volume 3": "The implicit write-back is transferred directly to the initial requesting processor and snooped by the memory controller to assure that system memory has been updated. Here, the processor with the valid data may pass the data to the other processors without actually writing it to system memory"
ggg>>1) Шину PCI не знаешь. Следует из первого твоего утверждения. A>"Наслышан" (c)
_Пока_ ты не продемонстрировал даже такого ("базового") знания. Хотя всё ещё претендуешь.
ggg>>3) Не знаешь инструкций тима "memory barrier" на IA32, некоторые из которых существуют с выхода Pentium III. A>Инструкции относятся к SIMD,
Неверно.
A>и появились в SSE/SSE2. При этом данные инструкции синхронизируют weak ordered memory,
Вот это уже верно. Пожалуйста, обрати внимание на объяснение термина "weakly ordered memory" в контексте IA32 в таблице 10.2 "Memory Types and their Properties" в "IA32 Architecture Software Developer's Manual. Volume 3: System Programming Guide". Никакой привязки к SSE там нет.
A>а не всю работу с памятью,
Можно без всеоъёмлющих понятий вроде "вся работа с памятью"? Есть широко распространённые и конкретные термины, давай их использовать.
A>и в применении в контексте "double checked lock" данные инструкции особого значения не имеют.
Верно, если память не WC.
A>Память у IA-32 действительно синхронизированная. Надеюсь с последним утверждением не станешь спорить?
Что именно _ты_ подразумеваешь под термином "синхронизированная память" один Бог знает, но уж память с атрибутом WC таковой точно не является (табличку-то 10.2 посмотри, да).
Резюме: ggg>>2) Ты путаешь проблему cache coherency с memory-ordering. ggg>>4) Не понимаешь смысла этих инструкций.
имеется серьёзная претензия на базовые знания в нескольких областях (PCI, программирование для SMP-систем и не-IA32 архитектур).
A>Процитируй где именно я заявлял "серьезную претензию в PCI". На SMP и не IA32 я действительно программирую(хотя тоже не заявлял).
Я написал "серьёзная претензия на базовые знания" (2). Четыре слова и предлог те так уж трудно воспринять, правда? А твоя заявка на базовые знания о SMP и не-IA32 элементарно вытекает из твоего же поста. Ты же описываешь A в контексте B и С; понятно, что это подразумевает понимание не только A, но и B с C. Ну, если заявка обоснована.
Это остаётся в силе: ggg>>Возникает вопрос по теме этого обсуждения, а нужны ли _такие_ базовые знания, качество которых лучше всего характеризует известная пословица про "слышал звон"?
A>1) Научиться читать и понимать текст, который они пишут, чтобы спорить с их утверждениями, а не с самовыдуманными утверждениями.
В этом сообщении я дважды продемонстрировал, как выдумываешь утверждения ты ((1) и (2)).
Не соизволишь доказать своё нравоучение?
A>2) Самому до конца разобраться в теме. Притом не на базовом уровне, чтобы человек с базовыми заниями не мог тебя поймать за 3 минуты с помощью гугла.
Это ты так предвидел ситуацию с твоим знанием mfence/sfence?
A>По теме обсуждения конечно нужны: я думаю большая часть людей здесь даже про double checked lock не слышало, при этом даже те не совсем юридически корректные знания которые я им сообщил позволяют найти в google информацию по вопросу. (И после этого с найденной информацией на меня начать наезжать ). Вот что выдаёт google.com по запросу "double lock PCI" (и не говори, что нужно искать без PCI или со словом checked; так в твоём первом сообщении). Сам-то найдёшь там "double checked locking"? Если да, то на какой странице?
Здравствуйте, Maxim S. Shatskih, Вы писали:
SR>>К тому же непонятно, что заставляет вас считать, что на 1200 лохов набежит меньше Может статься совсем наоборот. Пролема может решаться эффективным скринигом.
MSS>Скрининг и делался, чтением пачки резюмешек вот после такого скрининга на 1200 приходили в массе своей адекватные люди, а на 600 — все равно неадекватные.
Резюме кандидатов без опыта как правило очень субъективно (я рассматриваю ситуацию, когда кандидат раньше по специальности не работал). На его основании очень сложно принимать решение.
Если Ваше мнение основано на реальном опыте (тогда хотелось бы знать на каком именно), то возможно я с вами и соглашусь. Из общих соображений это совершенно не следует.
SR>>Этот подход применим (и вполне оправдан) к опытным разработчикам, доказавшим свою эффективность на практике. Но как раз в случае стажера никаких гарантий, как правило, нет. Даже в случае более высокой зарплаты.
MSS>Конечно. Переплата стажерам, собственно, вообще не дает ничего, кроме покупки их лойяльности.
Хорошая мысль. Надо сказать начальству чтобы он подняло мне зарплату вдвое. За лояльность
Здравствуйте Smetanin, Вы писали : > Кхм. Я придерживаюсь убеждения, что кто ясно мыслит, тот ясно излагает. > Так что если человек не может *ясно* сформулировать свои пусть даже > туманные остаточные знания — у меня возникают подозрения, что этот > человек нормально вообще ничего сформулировать не в состоянии. Ничего не > могу с собой поделать!!!
Утверждения совершенно неверные. Люди мыслят по разному. Иногда знания
просто играют злую шутку. Знание различных вариантов, в которых
утверждение "не совсем верно", может оказать влияние на ответ. Кроме
того, чуть неправильно заданный вопрос может поставить в тупик гуру, но
студент даст "правильный", на ваш взгляд, вопрос. Например, меня
поставил в тупик вопрос про особый способ построения составного индекса.
С моей точки зрения ничего "особого" там совершенно нет. Я знаю
особенности внутреннего устройства MSSQL, которые влияют на создание
вьюх, вот там, действительно, "особенности". А составные индексы это
примитив.
Помимо этого, существуют люди, которые держат в мозгу такое количество
вариантов и такое количество возможных последствий, что ответ на ваш
вопрос вполне может вылиться в лекцию на полтора часа. Причем, с Вашей
точки зрения, это будет бред полнейший, ибо о таких связях Вы попросту
не задумывались.
Posted via RSDN NNTP Server 2.0 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Smetanin, Вы писали:
S>На стажёра — не прошли бы точно!
Ну и не надо
S>Кхм. Я придерживаюсь убеждения, что кто ясно мыслит, тот ясно излагает. Так что если человек не может ясно сформулировать свои пусть даже туманные остаточные знания — у меня возникают подозрения, что этот человек нормально вообще ничего сформулировать не в состоянии. Ничего не могу с собой поделать!!!
Не, дело не в остаточных знаниях. Дело в том, что их не было Серьезно! Я довольно долго не знал определений инкапсуляции, полиморфизма (этого я точно не знаю и сейчас ), что там еще... Просто это все настолько очевидные вещи, что раздувать некую теорию относительно них не вижу особого смысла. Ну, то есть она наверное должна быть, но мне как-то побоку как это называется. Это вот как с синглтоном. Много раз встречал это слово (здесь на форуме), и в конце концов решил посмотреть...хм, красивое слово для глобальной переменной!
S>А так, в данных "определениях", например, инкапсуляции — на мой взгляд отчётливо сквозит опыт работы с COM (а вот с ООП они не имеют вообще ничего общего)...
Не поверите! С COM не работал!
S>...Принципиально разный взягляд на базовые вещи. Мы бы наверняка просто подрались через 15 минут любого обсуждения.
Хм. Горячие финские парни? Зачем? Это говорит лишь о том, что вы с трудом терпите чужое мнение... Это досадно
S>Мой вариант определения такой: инкапсуляция — объединение в одной сущности данных и механизмов работы с ними. Всё!
Ну вот, вы придумали свое определение и ждете, что другие будут думать так же... Ну-ну Можно долго кашу разводить вокруг этих определений, но я просто знаю, что если я сейчас поменяю поставляемый с MSVC++ STL на STLPort, то все будет работать, как и раньше (ну конечно при условии, что я не нарушил стандарт языка на интерфейсы STL). Если я перепишу функции для работы с настройками settings_store_value/settings_load_value с использования .ini на использование реестра, то все будет работать Т.е. по мне, так инкапсуляция это — абстрагирование от этих конкретных механизмов (т.е. создание некого прокси для их использования).
S>Дальше — пояснение: таким образом обеспечивается целостность данных в том смысле, что изменяться они будут только специально предназначенными для этого механизмами.
Т.е. это уже не определение, да?
S>Я хочу подчеркнуть, что инкапслуяция — это термин относящийся отнюдь не только к ООП. Например, при модульном подходе инкапсуляция данных и механизмов обработки производится в модули (вместо классов в ООП). В некотором смысле можно даже говорить о инкапсуляции локальных переменных внутри процедур!
И не только к программированию, я бы сказал Нам то пофиг, каким методом электростанция вырабатывает электричество, лишь бы она могла обеспечить нужную мощность.
S>И вот, если человек не понимает, что термин "инкапсуляция" — это не что-то, порождённое ООП (а наоборот, просто одна из основных составляющих ООП) — мне это говорит о том, что "взгляд на жизнь" и базовые понятия у нас сильно отличаются.
То есть, кто со мной — тот герой? Хм... На самом деле,
Если два работника думают всегда одинаково, то один их них — лишний. Если два работника думают всегда прямо противоположенно, то один из них — лишний. (с) не помню
S>Хмм... Интересно, насколько ясно излагаю я свои мысли? На всякий случай пример инкапсуляции в том смысле, в каком я понимаю термин: СУБД инкапсулируют в себе данные (собственно, БД) и средства доступа к ним (собственно, СУ). Ни один программист в здравом уме не полезет из своей программы напрямую менять файл, в котором СУБД хранит данные!
И предоставляет некий интерфейс для их использования...
S>А что касается "скрыты детали реализации" — это, на мой взгляд вообще не имеет отношения к инкапсуляции!
Хе-хе Забавно Скрыты может и не так подходит...лучше наверное сказать "детали реализации нас не волнуют!". Хотя они конечно должны волновать
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Avantasia — Breaking Away";
Здравствуйте, ansi, Вы писали:
A>Здравствуйте, Smetanin, Вы писали:
S>>На стажёра — не прошли бы точно! A>Ну и не надо
S>>Кхм. Я придерживаюсь убеждения, что кто ясно мыслит, тот ясно излагает. Так что если человек не может ясно сформулировать свои пусть даже туманные остаточные знания — у меня возникают подозрения, что этот человек нормально вообще ничего сформулировать не в состоянии. Ничего не могу с собой поделать!!! A>Не, дело не в остаточных знаниях. Дело в том, что их не было Серьезно! Я довольно долго не знал определений инкапсуляции, полиморфизма (этого я точно не знаю и сейчас ), что там еще... Просто это все настолько очевидные вещи, что раздувать некую теорию относительно них не вижу особого смысла. Ну, то есть она наверное должна быть, но мне как-то побоку как это называется. Это вот как с синглтоном. Много раз встречал это слово (здесь на форуме), и в конце концов решил посмотреть...хм, красивое слово для глобальной переменной!
Синглетон и глобальная переменная это разные вещи.
1. Ориетироваться в ООП: наследование, полиморфизм, инкапсуляция — должны быть для него не абстрактые слова.
2. Знать основные структуры данных: массив, связный список, очередь, дерево, стек и т.д.
3. Знать осноные приемы программирования. Должно быть некое понимание, что любое решение — это палка о двух концах. Т.е. например, можно получить прирост в скорости за счет увеличения памяти.
4. Общее представление о потоках, разделяемой памяти. (Тут я уже сильно сомневаюсь, т.к. на этом вопросе очень многие плывут.)
Мне вот интересно, если я все это в общих чертах знаю, но не на уровне определений, а на практике, я подхожу? На практике — это в том смысле, что я все это применял.
S>Нет. Сортировки — это базовые знания. Если ты не имеешь представления о базовых алгоритмах — ты не изучал программирование.
Что значит изучать программирование? Если у меня перед глазами MSDN, RSDN, Google, 3 книги по ASP.NET, 2 по C#, ADO.NET, несколько книг по HTML и JavaScript, но ни одной по С++ и уж тем более нет Кнута и иже с ними, можно ли сказать, что я не изучал программирования? Должен оговориться, я не программист по образованияю, да и по профессии тоже. Но по работе приходится выворачиваться, когда стандартных средств не хватает.
S>Вообще-то это тоже базовые знания. Если ты не помнишь приблизительно, как выглядит потоковый ввод-вывод, значит ты книг по С++ (например, Старуструпа) не читаешь вообще. Это значит, что ты как минимум ленив и нелюбопытен.
. От недоплаты две проблемы а) текучесть б) сложность набора персонала, причем пункт б) намного более ощутим. Кстати, можно удержать человека, который уходит исключительно по причине повышения денег. Столько же денег дать — и все. Естественно, это подразумевает, что, например, личные отношения с руководством у него нормальные.
).
На самом деле,
Скрыты может и не так подходит...лучше наверное сказать "детали реализации нас не волнуют!". Хотя они конечно должны волновать 
