Вопрос по C\C++ на собеседовании

После того как отправил резюме позвонили и начали задавать вопросы.
Сначала с «базовых» понятий.

Первый вопрос: Что такое таблица виртуальных функций?

Я приблизительно представлял что это такое, но четкого ответа не дал.

Мне кажется что это «базовое понятие» для какого то Java разработчика, но для плюсов это уже тонкости.

Как вы считаете?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Мне кажется что это «базовое понятие» для какого то Java разработчика, но для плюсов это уже тонкости.
а ти остряк

Для C++ это даже «более базово», чем для Java.

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

Может правильный ответ — это серия унизительных комментариев в стороны C++ с позиции C???

P.S. По идее, в Java это вообще знать не нужно, так как все функции виртуальные.

Я тут сегодня свежий баг нашёл в компиляторе VS2015+update2. Вобщем, если объявить структуру с алигном, типа __declspec(align(32)) struct Vertex {....}, то с дефолтными конструкторами копирования и оперторами присвоения код падает на релизовой сборке на платформе x64. Падает как раз в точке копирования/присвоения. В дебаге всё работает, и на x86 тоже всё работает, кроме того, работает всё без алигна. Баг можно обойти, если руками написать свои конструкторы копирования и операторы присвоения.

Падает, если на стеке заводить? А почему 32? Тогда уже 64.

Падает с ошибкой защищённого режима, если запустить релизную сборку. Тесты показали, что ошибка не в выделении памяти, а в коде дефолтного конструктора копирования/присваении для структур с алигном именно для x64. Поскольку в дебаговой сборке всё работает, а в релизной смотреть проблематично, расставлял MessageBox(...) до и после конструктора, и присвоения.

Помню в лабораторной надо было использовать WinApiшные функции потоков, и там была какая-то функция типо thread_create, которая в аргументах принимала ссылку на другую функцию.Так вот, когда она начала плеваться на ссылку функции, которая принадлежала классу, оказалось, что понимание внутреннего устройства не такое уж и бесполезное.

Все такие мое мнение: ...что это такое и как оно работает — знать нужно. А вот реализацию virtual table — это уже другой уровень.

Совершенно не обязательно знать, как она реализована. Важно знать, что она такое и зачем. Если на этот вопрос нет ответа сходу, то нужно было или оставаться в C, или переходить на какую-нибудь Java. Такие дела. Плюсы не любят дилетантство.

Колись на RSDN, хай йо’ фрас пуб’є, був гарний список питань по C++, вже трохи застарілий, на жаль.

rsdn.ru/...um/info/FAQ.cpp.questions

Вашого питання просто в лоба там немає, проте воно виникає при відповіді на деякі інші.

Щодо новачків — то це взагалі-то питання на екзамен.

человеки, а предполагается ли, что джун-плюсовик будет в курсе точек следования? просто интересуюсь

...Их не рассматривают на занятиях, о них редко пишут в книгах...
че уж там.

Про UB могут спросить, типа отетихвот
i = ++i++;

Один колишній колега порадив, що казати в таких випадках: «А ви таке в проекті використовуєте? Ну то чому питаєте?»

А ви таке в проекті використовуєте?
А як скажуть, що так, трапляється схоже. Ну як приклад
while(*strTo++ = *strFrom++);
Не схоже, хіба?)
І це взагалі погана порада. Сьогодні не використовуємо, затра будемо, не тільки власний код використовуємо. Та мало шо взгалі трапитися може.

В такому випадку треба бігти зі співбесіди, де безбожно говнокодять:)
А якщо вже працюєш, де таке трапляється, то колегам за таке бити по рукам. Не дарма існує порада: «Пишіть код так, наче підтримуватиме його маніяк, що знає, де ви живете ».

...про наслідки можливі не подумав.
Джун не отримає першу роботу. Лід запам’ятає, що якийсь прибацаний кандидат. А український хрестосвіт тісний. А лід може й не тупий і дійсно так не пишуть в них ніколи.

А лід може й не тупий
А нашо він тоді тупе таке питає с какой целью інтєрєсується?

Тут протилежне треба доводити, бо однозначно не виходить з таких питань, що він тупий. Трапитись всяке може. Тільки з пилу з жару на співбесіду, які ніколи не проводив, знайшов щось швидкоруч, що питати. Або травма дитинства, де він дійсно погорів на подібному. Або религійні вподобання (що можуть і не дуже впливати на те, що дійсно пишуть).

Ще раз повернуся до класичного співбесіда насправді завжди двосторонній процес і кандидату потім з цим «лідом з травмами дитинства за релігійних вподобань» працювати.

Звичайно. Але що з іншої сторони в кандидата, що полюбляє не відповідати на питання та сперечатися на співбесіді та про UB не в курсі?

да ладно, забаните джунів, хто роботу буде робити?

А де в цьому випадку неоднозначність? Спочатку виконуються * зправа на ліво, потім =. Постфіксні ++ виконуються після того як операнд прийняв участь у виразі, тобто можуть і після *, і після = і на результат це не впливає.
en.wikipedia.org/...d_C++#Operator_precedence

Може бути неоднозначність, але не через ++.
Якщо там aliased pointers, load/store може бути не в тому порядку.

c-faq.com/expr/confused.html #3

Тут нема, да) Типовий приклад копіювання строк. Не без тонкощів, але до UB вони не відносяться. І якщо кандидат скаже просто, що тут неоднозначностей нема, то наступне питання, «а що це за такі неоднозначності у вас і коли вони виникають?»

Саме так, більше однієї точки слідування.

Почему в Украине не в курсе кто такой Junior ? Куда не придёшь, вопросы такие, которые и senjor не всегда знает...

Скорее всего, дело в том, что претендентов на Junior-должности намного больше, чем самих должностей, потому как-то (например, с помощью сложных вопросов на собеседованиях) нужно выбирать самых лучших.

Смысл тогда искать Junior... Откуда он может знать ответ, если не когда с этим не сталкивался, а если знает, то смысл тогда идти на заниженную зарплату ?

На Junior-позиции часто претендуют, например, студенты, и то, что их зарплата ниже, чем у миддлов, вряд ли их сильно напрягает. Также junior-зарплаты как правило выше средних по стране или городу зарплат и есть немалые шансы увеличения зарплаты после нескольких месяцев или года работы, так что с экономической точки зрения это может быть выгодно. Из-за этого возникло движение «войтивайти», когда менеджеры, экономисты, юристы и т.д. внезапно осознают то, что им всегда хотелось программировать.

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

Смысл тогда искать Junior...
зарплата другая.
то смысл тогда идти на заниженную зарплату ?
ну пусть тогда идет на синьорские вакансии. в чем проблема для соискателя выбрать те вакансии, которые он считают достойными для себя?

Удачи Вам в поиске работы.

ОМГ, скоро форум ДОУ можно будет читать вместо Лепры :)

однако поколение «вайтивайти» начинает доставлять)

Вопрос про VFT это вопрос о механизме а не о реализации этого механизама. Т.е. достаточно было рассказать что такое «виртуальная» функция, когда ее вызов приведёт к ожидаемому результату а когда нет и почему. Всё!

Для джависта это нафик не сдалось, а вот сишник и тем более плюсовик должен знать. Обычно спрашивают а как бы вы сделали классы с наследованием на C :D

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

как раз эта таблица и есть «тонкости» реализации
можете привести часть стандарта С++ в котором она описана?
С другой стороны такие вопросы на собеседовании имеют право задавать — они позволяют понять уровень понимания языка и того как все работает

Что такое таблица виртуальных функций?
Тут здається хотіли чітке визначення що воно таке і для чого, а не те, як вона реалізована

К чему здесь стандарт? В стандарте это не описано, но это не значит, что на это можно забить. В реальных проектах, которые пишутся на C++, практически всегда учитывается и используется что-то, о чём нет ни единого упоминания в стандарте. Зачастую таких вещей в проекте подавляющее большинство, особенно если он ориентирован на конкретную(-ые) платформу(-ы), из возможностей которых нужно выжать максимум, а не на идеальную переносимость между всеми мыслимыми и немыслимыми платформами.

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

На практике же почти все компиляторы в том или ином виде реализовывают диспетчеризацию виртуальных вызовов через таблицу виртуальных функций. Да, детали реализации в каждом компиляторе (и даже в разных версиях одного и того же компилятора) свои, но общий принцип соблюдается практически везде. И понимать его нужно, если уж пишешь на C++, а не на каком-то более абстрагированном и высокоуровневом языке (тем более, что эти вещи даже в книгах по C++ объясняются).

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

Например:

class vec2 { float x; float y; public: virtual float magnitude() const { return std::sqrt(x*x + y*y); } };

Почему выполнить memset(), забивая нулями целый объект такого класса, — грубейшая ошибка и выстрел себе в колено? А если бы виртуальных функций в классе не было, то это вполне легитимно можно было бы делать. Как это объяснить?

Или другой пример: в программе создаются миллионы объектов подобного класса, у которого только два поля — два маленьких несчастных float’а, но виртуальных функций пока нет, а начинающий программист по какой-то причине взял и добавил в этот класс виртуальную функцию — и с удивлением обнаружил, что объём занимаемой памяти вырос в два раза. Как? Почему? Что случилось?

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

Первый вопрос: Что такое таблица виртуальных функций?
самое смешное что недавно я коллеге джависту пояснял что такое инлайнинг метода, как, при каких условиях JVM инлайнит методы, и вышел для показа сложностей, как в общем устроены таблицы виртуальных функций в С++, и почему JVM легче и без подсказок в виде private и final принять решение об инлайнинге, а вот ++сному компилятору практически невозможно.
Мне кажется что это «базовое понятие» для какого то Java разработчика, но для плюсов это уже тонкости.
ИМХО, наоборот. джависту можно и не знать что все методы в Java — виртуальные. кроме .... (на собеседовании ответите :D
а плюсовику — иметь представление стоит. но конечно не для того чтобы по указателю memsetом тереть данные объекта. как уже писали — за такое — руки отрубать нужно. Или — отправлять откуда пришел — на plain C

я бы еще задал вопрос о работе и реализации «в известных вам компиляторах» исключений при собеседовании ++совика.

Наприклад функція може бути імплементована в іншому модулі і компілятор просто не знає що саме треба вставляти. Або увімкнена оптимізація по розміру.

Кстати, а почему?
открываем википедию и читаем:
Виртуальный метод (виртуальная функция) — в объектно-ориентированном программировании метод (функция) класса, который может быть переопределён в классах-наследниках так, что
!!! конкретная реализация метода для вызова будет определяться во время исполнения !!!
т.е. в месте вызова такого метода на этапе компиляции неизвестно какой метод будет выполнен.

(пишем в уме — человек не знает что такое виртуальный метод даже на уровне Википедии)

В студии всегда ставил настройку «инлайнить всё что можно» в релизной версии.
GlobalLogic’у конечно видней.

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

нерелевантные впоросы на собеседовании и попытка более опытных программистов самоутвердиться за счёт менее опытных
это конечно, это понятно. озабоченные местом в жизни подозревают во всех окружающих тот же мотив :D на другие мотивы у них фантазии не хватает.
На работе у меня есть более опытные коллеги для таких вопросов
поэтому и сказал что GlobalLogic’у видней. как и более крупным корпорациям видней, зачем они заказывают работу у «пакистанцев».

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

Мужик, ты болен, я думал ты просто на политике повернут, но ты и в технических темах ведёшь себя как полное...

то есть такие как вы эксперты в психиатрии ни в политических темах, ни в технических не в состоянии писать по делу?

Если честно в треде где ты, вообще никакого желания ни писать ни читать.

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

C++ оптимизаторы могут инлайнить виртуальные методы, если удается получить информацию о рельном (динамическом) типе. Процесс называется девиртуализацией. Например, из release notes по GCC 5:

The devirtualization pass was significantly improved by adding better support for speculative devirtualization and dynamic type detection. About 50% of virtual calls in Firefox are now speculatively devirtualized during link-time optimization.

(пишем в уме — у кандидата гонора гораздо больше, чем реальных знаний и опыта)

C++ оптимизаторы могут инлайнить виртуальные методы, если удается получить информацию о реальном (динамическом) типе.
да :)
в изначальной фразе моей «практически невозможно» и был намек что вообще-то — возможно, хотя и определение «виртуального метода» указывает на фундаментальную невозможность.
ожидалось что кто-то и скажет, постойте, а вот есть такая оптимизация....

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

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

Так что вы соискателя на программиста по С++ подловите на этом, который не знает как устроены таблицы виртуальных функций и скажет что
виртуальные функции низя заинлайнить по определению!

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

кстати, а что будет с таким кодом, где виртуальный метод уже вычислен, и заинлайнен, когда мы подлинкуем бинарник в проект, в котором расширим класс — переопределением метода?

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

Инлайнится не все подряд
Вы внимательно читали, что я написал?
приведите цитату где я написал что инлайнится — все.
то вы мне закидываете что написал что «виртуальный метод» никогда не инлайнится, то уже приписали что я написал что инлайнится все подряд :)
то очевидно же, что ничего не заинлайнится изначально.
мне тоже многое кажется очевидным. когда понятен — принцип.
но, как много где на просторах интернета, выясняется что очевидное мне — вовсе не очевидно как норма. что со знание принципов — ненормально.
если функция/метод экспортируется из библиотеки
конечно. потому что принципиальный вопрос все тот же — обладает ли компилятор полной информацией для принятия решения, или нет. как выше я написал — известен ли ему весь контекст вокруг выражения с вызовом — или нет.
и тогда — пишешь ты на С++ много лет, или не писал никогда вообще — вопрос из возможностей реализации компилятора, не знания ЯП.

а про VMT я читал у Страуструпа. в одном из первых на русском изданий, году в 93-ем. Интересно было освежить в памяти. да и проверить — принципы ее то помнишь? причины ее появления? и т.д.

в википедии кстати в статье Таблица_виртуальных_методов все в общем написано.

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

Поддержу. Инлайнить виртуальные методы как минимум странно. Даже в понимании оптимизации.
Читал у того же Страуструпа, что для программирования на С++ нет необходимости знать все особенности языка.
Для любого языка существуют весьма странные особенности, неизвестные а иногда умалчиваемые создателями языка. Часто бывает то, что невозможно было в ранних версиях, становится возможным в последних...

Читал у того же Страуструпа, что для программирования на С++ нет необходимости знать все особенности языка.
Степанов, автор STL (если не путаю после виски), на лекциях в Яндексе сказал что спеку С++ он асилил дай бог на треть. он там потом по трезвяни стал про Платона с Аристотелем гнать. но ему можно ж :)

и ему — верю :) т.е. верю что он ее всю пробежал бегло не раз, но понял и использовал — на треть. и «типичное собеседование по С++» — провалит :)

Для любого языка существуют весьма странные особенности,
стопицот плюсов!

главное, чтобы собеседующий на свои вопросы правильно ответил

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

интересно?
«В каких случаеях установка z-index не будет работать?»

теоретически я в любой момент по скайпу отвечу :)
но практик даст правильный ответ, который шире моих знаний.

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

С++ - работа титаническая как в позитивном, так и в негативном смыслах.
не я придумал, но согласен.

Думаю, в конце концов они придут к тому, чтобы разрешить эти проблемы.
Врядли. я почти не слежу, но пара статеек для убогих(я о себе) о последних нововведениях и роадмапе говорит о том что титаническая работа (опять в обоих смыслах) — продолжается!

то есть — С++ проще точно не станет. а логичней да, но только на уровне логики второго порядка :)

при этом, при всем уважении к сонму святых в лице Фаулера, «Дялюшки Боба» — Страуструп «похоронен» несправедливо. говорят — низя при жизни памятники ставить. а хоронить значит можно? я о АйТи медиа пространстве.

И кто же вам запретил ромбовидное наследование в С++? Ромбовидное наследование в С++ называется виртуальным наследованием. Да и в природе встречатся множественное наследование, например, скрещение видов. В общем, мне кажется, вам обоим стоит немного подучить предмет о котором пытаетесь рассуждать, а то ваш диалог совсем стрёмным получается.

Где вы видели, в природе, чтобы камни скрещивались с бегемотами, собаками и деревом? В C++ такое можно сделать легко (точнее такое делают «кодеры»).
Виртуальное наследование это не то о чем я говорил. Если у общего предка метод будет виртуальным, то существует дилемма, от кого этот виртуальный метод вызывать. Программисту должно быть предоставлено право выбирать, от какого предка какое свойство будет передано потомку. Как в реальном скрещивании, окрас может быть унаследован или смешан, лапы одного предка, хвост другого — определяется программистом. Там еще много чего странного есть... целые книги писать можно. И все от того, что кто то ударился головой о подоконник при разработке спецификаций.

Ты слишком много фантазируешь и сам не понимаешь о чем говоришь. Ты же заявлял, что в С++ нет ромбовидного наследования? Оно есть. Так же ты можешь выбирать свойства от разных объектов. Тебе никто не мешает.

В С#, Java и других ООП языках, тебе так же ничто не мешает добавить к классу бегемот интерфейс свойственный только камню и его реализовать.

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

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

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

en.wikipedia.org/wiki/Human_genome
Плавающая табличка в начале страницы.
В привычных цифрах ~770 мегабайт.

?
455 экзабайт данных (около 100 млрд DVD-дисков)

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

455 экзабайт данных (около 100 млрд DVD-дисков)

Откуда такие цифры? Объём генома легко гуглится.

Используя суперкомпьютеры и десятки лет смогли расшифровать только часть информации

en.wikipedia.org/...wiki/Human_Genome_Project

P.S. Грубая прикидка даёт массу днк на 450 экзабайт порядка 2г. Это одна-две чайные ложки сухого порошка минимум.

Это как число бит и числа которые можно представить с помощью такого числа бит. 8 бит — 256 комбинаций. 32 бита — в состоянии кодировать 2 в степени 32 . У ДНК не двоичная система кодирования. Объем возможного кодирования состояний никто не в состоянии даже представить. Значит говорите 2 г порошка :)

Это как число бит и числа которые можно представить с помощью такого числа бит.

Мысль не понял. У 2GB файла объём 2GB или 2**(2GB) ?
Точно так же с геномом. В байтах меряется разрядность, а не количество вариантов.

У ДНК не двоичная система кодирования.

Ну четверичная, это вроде не принципиально.
1 байт = 8 бит = 4 базовые пары.

Объем возможного кодирования состояний никто не в состоянии даже представить.

А какие проблемы? 4**Nbp, где Nbp число базовых пар.

Только это число без смысла. Произвольно взятая последовательность длиной 3e9 бп не кодирует человека. И ничего живого не кодирует. Точно так же как выхлоп /dev/random объёмом 770MB не является исполняемым файлом.

«А говорил романтик!» Берете лист бумаги и рисуете граф-схему алгоритма. Начало, if одно действие, else другое, конец. Для проверки работоспособности программы вам надо ровно 2 тестовых комбинации. Добавляете еще один if в одну из ветвей первого if. Для установления правильности последовательности вам надо будет (упрощенно) 2 в степени количества if. При наличии всего 32 if в программе вам необходимо будет отследить 4 294 967 296 тестовых последовательностей. Даже если вы потратите на каждый тест 5 секунд (допустим вам не нужна еда и сон) вам понадобиться всего 680 лет! Так вот, предсказать поведение алгоритма ДНК человека, если ВСЕ население земли будет этим заниматься, займет триллионы триллионов лет. Вот такова примерно сложность алгоритма, заложенного в ДНК. Поэтому ни один человек, никогда, не сможет использовать такую программу, даже с применением супер компьютеров. А вы говорите про какие-то граммы. Это все равно что измерять расстояние в килограммах.

Это самый близкий вариант из возможных для объяснения :) Есть немного другой вариант, но думаю вам еще сложнее будет понять. Например элементарная схема умножения 4×4 бита gorgeous-karnaugh.com/...usage/multiplier-4×4.html Для проверки там используют скрипт, который генерирует тестовые последовательности. Разумеется в случае ДНК человека написать такой скрипт не представляется возможным, как и контроль полученной последовательности объемом в сотни экзобайт.

ПС: если не понятно, то можно послушать www.youtube.com/watch?v=R0sw2CgysWY

Я тоже хочу что б он со мной поделился веществом....

А вы думали дыры в по и баги зависят только от программистов?

ПС: все взаимосвязано. Так же и компиляторы, любые программы. Сложность растет до определенных пределов (количества if). Как только количество костылей (if) превышает определенный порог, программу уже невозможно поддерживать из-за растущего количества не тестируемых последовательностей. Как правило такую систему называют "гуано"-код.

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

Одна ДНК имеет больше информации чем все программы созданные человечеством за всю историю своего существования. Вы даже на миллиардную долю процента не приблизились к такому же качеству программ и при этом утверждаете, что мир консервативен. Это смешно!
«Вы» — это человечество, я понял. А ты тогда Кто? Неужели сам Создатель пожаловал на форум? Почто столько болячек и багов в ДНК захерачил, а? У меня даже объекты на С++ столько багов не имеют, а перед удалением предупреждаются деструктором.))
не знать что все методы в Java — виртуальные. кроме ....

кроме тех, которые помаркананы модификатором final или те, которые private, но не переопределяются наследниками.

а что со static?
(пишем в уме — знания поверхностны)
...
итого, вот так и выходит, «Спасибо, мы вам перезвоним» и конечно никто не перезванивает.
и темы потом на доу — хожу я по собеседованиям хожу, хожу-хожу, и отвечаю на все вопросы

Я думаю, что если на собесе по Java мне задали такой вопрос и я бы на него ответил в той форме как я написал, то мою кандидатуру хотя бы рассмотрели на дальнейший этап =)

ПЫСЫ static methods are not virtual once mb the issue is that you cannot override them.

Я думаю, что если на собесе по Java мне задали такой вопрос и я бы на него ответил в той форме как я написал, то мою кандидатуру хотя бы рассмотрели на дальнейший этап
вполне. ведь главное в соискателе — способность к работе :) практически не выявляемая характеристика.

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

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

я потом узнал, что мне НЕ повезло, это был один из самых суровых технических собеседователей в компании.
сейчас собеседовавший меня 2 года в Амазоне работает.

так что, да, вполне :) я просто о том, как во время собеседования накапливаются «минусы». на мелочах.
у меня старый хороший приятель, на джаве не один год, но вынужден фрилансить. «плавает» и постоянно проваливает собеседования, накапливая такую негативную мелочевку. хотя практики у него более чем.

ПЫСЫ static methods are not virtual once mb the issue is that you cannot override them.
конечно :)

волею судеб я сейчас собеседую phpистов. про «позднее статическое связывание» в php прекратил спрашивать и реальных мидлов. не помогают и наводящие вопросы чем отличается обращение self:: и static::

как и про многое другое, что мне казалось естественным что phpист это должен знать...

открою один из вопросов, который продолжаю задавать, потому что продолжаю пребывать в ступоре от «ответов».
как в php получить первый элемент массива.
отказываюсь поверить что это не элементарный вопрос, а какой-то глубинно-академический, типа:
расскажите об отличиях в интерпретации выражений типа $foo->$bar[’baz’]() в php <7 и php7

но, народ же годами педалит, за плечами не один успешный проект, наверное и правда — на кой это все знать?

Это все имеет смысл знать, если это кардинально улучшает решение задачи. Если пишешь какую-то бизнес-хрень на php, то улучшать там банально нечего, и соответственно нет никакого смысла знать детали.

Если пишешь какую-то бизнес-хрень
ну, я всю жизнь только это и пишу — бизнес-хрени.
начиная с первой работы, plain C.
не, вру, был эпизод в пару лет гейм-дева
то улучшать там банально нечего
«покажи свой код» — это не о проекте в целом. это об уровне автора.
примерно как оценка собеседника по словарному запасу, и количеству всяких словей паразитов. не заглядывал в тему кто такие синьоры. думаю там все это обсуждается.
соответственно нет никакого смысла знать детали.
мне пока непонятно как годами разрабатывать на php и обходится без — получить первый элемент массива :)

а про php7 — после его выхода, ИМХО, стоит писать код который потом не придется проверять на совместимость. сейчас многие известные проекты поставили в приоритеты — совместимость с php7.

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

т.е. — качественный код не улучшает проект. он уменьшает риски накопления технического долга. потому что — на рефакторинг никто тебе времени не даст. писать поэтому нужно сразу толково, временное это — навсегда
по другому — качественный код это не для увеличения «доходной части» сейчас. это для уменьшения «расходов» будущих периодов, если применить: прибыль(успех) = доходы — расходы
«доход» обеспечивают маркетологи, сейлсы, архитекторы, тех лиды, а не программисты.
зато программисты могут добиться такой расходной части, что «прибыли» не будет :)

Ну я на пхп пишу редко и только в духе «google://sql query php» -> строчка кода, «google://http request php» -> строчка кода, и т.д. Но первый элемент массива это $arr[0], разве нет?

Но первый элемент массива это $arr[0], разве нет?
в массиве
’first name’ => ’Dmitry’,
’second name’ => ’Dziuba’
?

понятно. вот я с этого и пока фигею.

так как мы не на собеседовании, вопрос к вам
когда вы в последний раз пользовались ссылкой
php.net/manual/ru/ref.array.php

и если никогда — то почему?

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

Но, опять же в данном конкретном случае, по этой ссылке я не вижу хорошего решения. Как можно вытащить первый элемент быстро (array_values хороши пока в массиве с десяток элементов, боюсь на 100к будет не так весело), и не портя массив (array_shift это конечно хорошо, но не всегда массив можно менять)?

ага, уже прочитал ответ ниже. Не, по названию «reset» мне не пришло в голову искать нужную функцию ))

вы думаете я его искал по названию когда в первый раз открыл php?

не, я как и с другими языками почитал — что есть в системной библиотеке, что «из коробки» она умеет делать.

запоминать названия — то уже лишнее. обычно они либо логичные, либо запоминаются в процессе постоянного применения.

то есть — вы никогда не открывали указанную ссылку?

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

Но — я читал ее так же внимательно, как и вы — мой ответ ))

ответ был -

$arr[0],
остальное — да, конечно хорошо что задумались и прочли наконец документацию.
array_shift кстати предлагают чаще, чем ваш второй вариант.
еще предлагают foreach и в его конце break;

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

ответ был -
Нет. Ответ был
Ссылкой пользовался пару месяцев назад, когда был как раз тот день, когда я писал на пхп ))
Я читаю документацию тогда, когда нужно решить задачу. Держать в голове хоть какие знания о пхп — неэффективно, с учетом того что я пишу на нем менее тысячи строк в год
Держать в голове хоть какие знания о пхп — неэффективно, с учетом того что я пишу на нем менее тысячи строк в год
понятно.
надо будет подумать и нашим эйчарам как-то пояснить что они отбирают резюме соискателей на «программист PHP, middle» пишущих на PHP менее тысячи строк в год....
Нет. Ответ был
в ответе — $arr[0] — и комментарии от Anton Kononenko «просто если надо работать с упорядоченной последовательностью» — есть еще интересный момент — самовольное упрощение задачи, принятие самых тривиальных вариантов как основных.
впрочем это не удивляет. это как раз привычно :)
Я читаю документацию тогда, когда нужно решить задачу.
то есть, словив E_NOTICE на варианте $arr[0] вы прочли бы документацию и написали бы что
array_values($array)[0] ))
или
reset($arr)
?
не спора ради. себе ответьте :)
не спора ради. себе ответьте
Лучше ответьте себе, зачем вы все это пишете )))

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

или, как в тестовом задании, человек например пишет
array_push($a, ’foo’ )
вместо
$a[] = ’foo’

если так принято, использовать array_push, то выяснить бы почему, и больше не задавать дурацких вопросов по синтаксису языка PHP — как добавить в массив элемент.

а зачем из ассоциативного массива первый элемент?
reset($arr) ?

reset($arr)
конечно.

я не понимаю почему мне пока на собеседованиях никто не может дать этот, ИМХО очевидный ответ.

а зачем из ассоциативного массива первый элемент?
хм. не «понял вопроса».
это ведь вопрос
«зачем нам получать первый элемент коллекции?»
никогда не было нужды что-ли?

просто если надо работать с упорядоченной последовательностью тогда классический массив как по мне удобнее.

просто в виду того что это на практике почти никогда не надо люди и не знают ответа

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

запомню, это многое объясняет :)

а почему с упорядоченной? в жизни только упорядоченные коллекции?
не только, но когда есть понятие первый элемент — коллекция имеет порядок
то есть это я такой везучий — у меня обычно данные приходят если и упорядоченные, то не так как мне нужно.
по ходу вы победитель по жизни =)

если серьезно, я знал этот ответ только благодаря тому что у меня н-лет назад был какой-то странный кейс (который я дяже не помню), что мне пришлось напрямую работать с курсором

не только, но когда есть понятие первый элемент — коллекция имеет порядок
в непустой коллекции всегда есть первый элемент.

но, решил проверить, может я чего не понял, смотрю в вики:
Последовательность — это набор элементов некоторого множества:
— для каждого натурального числа можно указать элемент данного множества;
— это число является номером элемента и обозначает позицию данного элемента в последовательности;
— для любого элемента (члена) последовательности можно указать следующий за ним элемент последовательности.

я о таких последовательностях, коллекциях, хэшах, ...
в PHP да, название «массив» не совсем правильное. там у них не массив, хотя название array. но такова там устоявшаяся терминология.

а вы какие последовательности имели ввиду?

по ходу вы победитель по жизни =)
если серьезно, я знал этот ответ только благодаря тому что у меня н-лет назад был какой-то странный кейс
понятно. надо будет проконсультироваться на каком-то форуме phpистов насчет этого вопроса.
потому что например классический вопросы — сколько типов данных в PHP, выявляют только лишь то что человек готовился к собеседованию по списку классических вопросов :)
по ходу вы победитель по жизни =)
это да. и попадаю в итоге в такие же везучие компании.
например у нас фронтендщики с джавистами и наоборот все время выясняют отношения — «почему jsonы не такие вы нам присылаете?». нередко заканчивается митингом, где ПМ в качестве третейского судьи зачитывает бизнес-требования. по которым оказывается не повезло ни фронтендщикам ни джавистам — у обеих команд — не те jsonы.
а вы какие последовательности имели ввиду?
когда мы говорим о ассоциативном массиве работающий по принципу key => value, то я мыслю о нем примерно как описано тут ru.wikipedia.org/...wiki/Ассоциативный_массив то есть я исхожу из того что порядок не оговорен, а соответственно не факт что не соблюдается, хотя это как раз не случай ПХП. в особенности если говорим о JSON для передачи данных который является сабсетом JS, то у объектов в JS порядок ключей не гарантирован (и на это натыкаются).

так как пишу я часто на разных языках, то исхожу из того что если я в ПХП использую ассоциативный массив то люди пришедшие не из мира ПХП (а такое часто бывает, к примеру у меня сча Java второй язык, а основной JS) могут удивится зависимости на порядок у ассоциативного массива. как-то так

то есть я исхожу из того что порядок не оговорен
и я исходил из этого.
исхожу из того что если я в ПХП использую ассоциативный массив то люди пришедшие не из мира ПХП
я пришел из мира Java. и никогда ранее не знал что получение первого элемента какой угодно коллекции зависит от того что ее элементы имеют ключи.

В Джаве задача уже будет звучать конкретнее
Получить из Map первый элемент.
см методы интерфейса:
Interface Map<k,v>
...
Collection<v> values()
смотрим Collection
Iterator<e> iterator()

обработку ошибок опускаю.
итого (в скобках объекты типа)

(Map<k,v>).values().itetator().next()

я получил первый элемент, или не получил?

то у объектов в JS порядок ключей не гарантирован
зачем для получения первого значения коллекции — какие-либо гарантии порядка ключей? не пойму.

мне какая-то функция вернула array с линками на банеры.
какая мне разница что там за ключи, для того чтобы вывести — первый из них?

могут удивится зависимости на порядок у ассоциативного массива
какой зависимости на порядок ключей? при чем тут -ключи?

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

и как ни индексируй элементы последовательности, она останется последовательностью если см выше

Последовательность — это набор элементов некоторого множества

я получил набор записей из реляционной БД. мне надо получить из этого набора — первую.
какая разница какие индексы использовались и какой ORDER BY стоял, если мне надо — первую из ответа?
ну изменится в запросе условие ORDER BY, и? нельзя будет получить — первую запись?

У меня кстати родился вопрос:

Как упорядочить последовательность чтобы у нее перестал существовать первый элемент?
второй есть. энный есть. последний есть. а вот чтобы первого — не стало.

Смотрите, я имею ввиду что когда не гарантирован порядок, понятие первый элемент, не имеет практичкого значения, ибо он может быть каждый раз разный.

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

Ответ на ваш вопрос — сделайте двусвязанный циклический список

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

в вершине стека то 4, то 8, то −115.

Вы не можете гарантировано получить тот же самый результат
а зачем мне получать «гарантированный результат», если мне нужно обслужить первого в очереди?
Поэтому оно не имеет особого практического значения
очередь не имеет практического значения?
Ответ на ваш вопрос — сделайте двусвязанный циклический список
то есть в нем не будет первого элемента, но будет второй, энный и последний?

извините, мы на русском языке хоть общаемся?

подумалось, а может вам задачки стоит решить
1. Вы участвуете в соревнованиях и обогнали бегуна, занимающего вторую позицию. Какую позицию вы теперь занимаете?
2. Вы обогнали последнего бегуна, на какой позиции вы теперь находитесь?

вы подменяете понятия мы говорили за ассоциативный массив, который не имеет порядка, а не за очереди и стеки которые явно упорядочены.

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

мы говорили за ассоциативный массив, который не имеет порядка
то есть
(Map<k,v>).values().itetator().next()

array_values($array)[0])) или reset($arr)
НЕ получают первый элемент?

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

Пример. Отсортируйту List запихните по порядку значения в HashMap, попробуйте получить первый элемент по порядку исходя из сортировки (ключи не привязаны к порядку).

В случае Java кода вы получаете некое первое значения
конечно я не знаю какое значение получу. если б знал, то зачем мне его получать.

но оно — ПЕРВОЕ ж?

Map это может быть не логический первый элемент
он ПЕРВЫЙ или нет?
Отсортируйту List запихните по порядку значения в HashMap
сделал.
(Map<k,v>).values().itetator().next()
вернет ПЕРВЫЙ элемент из объекта с интерфейсом Map?

отсортировал еще раз List, с другим компаратором.
поместил в HashMap
(Map<k,v>).values().itetator().next()
вернет ПЕРВЫЙ элемент из объекта с интерфейсом Map?

может так вы поймете что я пытаюсь сказать

void test (List<Object> list) {
    Map<Key, Object> map = new HashMap(list.size()); 
    list.sort(sorter);
    for (Object val : list) {
        map.put(new Key(), val);
    }
    
    if (map.values().itetator().next() == list.get(0)) {
         System.out.println("Are you sure that this will be ever printed?");
    }
}
может так вы поймете что я пытаюсь сказать
зачем, с какой целью, для получения ПЕРВОГО элемента
нужен этот код — if (map.values().itetator().next() == list.get(0))

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

Откланиваюсь статьей из толкового словаря русского языка
-ое. I. числ. порядк. к Один (1 зн.). II. прил. 1. Первоначальный, самый ранний; происходящий, действующий раньше других. П-ое впечатление. П. посетитель. П-ая встреча. П. рейс. П-ое время (сначала). П. удар (упреждающая бомбардировка военных объектов противника). П-ая волна эмиграции.

я не додумываю ТЗ. просто кейс не имеет практического смысла

выберите первую пчелу в рое. дайте первой зерно из банки с зернами. дайте первого человека из толпы.

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

для меня слово первый в контексте программирования имеет следующий смысл

имеющий номер один, начальный, идущий раньше других в ряду однородных объектов
только беда здесь в том, что ряда как такового не существует, а то что вы придумали себе его для технических целей, его рядом логическим не делает.
выберите первую пчелу в рое. дайте первой зерно из банки с зернами. дайте первого человека из толпы.
рой, банка и толпа НЕ соответствуют определению последовательности.
для меня слово первый в контексте программирования имеет следующий смысл
сходите в гугл
get first element from Map
get first element from php array
рой, банка и толпа НЕ соответствуют определению последовательности.
толпа людей прекрасно определяется через Map — где ключ — имя, объект сам человек. вы можете их опросить, в любом случае вы с кого то начнете и он и будет ваш первый, но он появился только когда вы начали их опрашивать, хотя первого в рамках толпы не существует.

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

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

а пока мы не определили толпу как Map, где ключ имя, то и толпа это никак не Map.

но в реальности для этого Map он не первый — он первый попавшийся
да. он первый попавшийся, но не первый. да.

интересно, если мою задачку изменить, на
получить из массива какой-нибудь элемент, то что, народ будет просто брать «первый попавшийся» или начнет таки rand(0, count($a)) пристраивать.
и доказывать обратное — что reset($a) — это первый, а не «какой-нибудь»
что «какой-нибудь» — это обязательно rand надо!

именно поэтому я говорю что это не логически первый для самого Map
да я понял что вы не состоянии абстрагироваться от понятия «сортировка».
вы хотя б знаете что сортировать можно по разному?
толпу например — не по имени а по фамилии. или по году рождения. или по знаку Зодиака.

а возвращаясь к array в PHP
он там не только Map. что написано в документации, которую не принято читать.

Он — сохраняет порядок добавления, независимо от значения ключей.
и поэтому с ним можно спокойно работать и как FIFO, и как с LIFO очередью.

именно поэтому я говорю что это не логически первый для самого Map
первый это тот кто будет получен первым. и все.
а все эти придумки про «логически первый». нет никакого «логически первого», это ваш какой-то язык, а не программерский или русский.
можно только сказать — такой-то элемент, в коллекции с таким-то порядком сортировки будет получен — первым.
или — первым всегда будет получен элемент с такими-то соотношением к остальным элементам множества.

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

-----

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

я не спорил с тем что ввиду технической реализации в PHP ассоциативных массивов, там порядок соблюдается.

я говорил о том, что если используется ассоциативный массив именно как ассоциативный массив (не стек, не очередь, не последовательность), то порядок не имеет значение, для людей которые его используют, оттуда и незнание

-----

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

я вам говорю о природе вещей
философ? ;)
намного важнее знать как передается массив по ссылки/по значению/то как на самом деле.
имхо это вопрос для трейни.
мне и в голову не приходило его задавать людям у которых профессиональный стаж (то есть пишут код за деньги) более полугода.

Я не философа не тяну. Просто чтобы понимать как строить программное решение, надо понимать суть процесов которые автоматизируешь

К сожалению не все мидлы знают ответ на этот вопрос... но может вам хорошие девы попадаются.

он ПЕРВЫЙ или нет?

Первый где? Первый элемент чего?

В Map нету первого (и любого n-го) элемента.
В неявном списке, который вам даёт values(), первый элемент есть.

вернет ПЕРВЫЙ элемент из объекта с интерфейсом Map?

Нет. Из Map вы получаете какой-то элемент.
Из Map.values() вы получаете первый элемент в Map.values().
Номера в объекте с интерфейсом Map у этого элемента всё равно нет.

Первый где?
в коллекции значений.
Первый элемент чего?
коллекции значений.
В Map нету первого (и любого n-го) элемента.
да ну нах :)
Нет. Из Map вы получаете какой-то элемент.
если уж браться читать приведенный мной код, то
из Map я получаю коллекцию значений, для которой получаю итератор, и вызываю next.

я ж не написал (Map<k,v>).entrySet()
У Set да, нет итератора. впрочем и для Set можно получить первый элемент, вызвав toArray()[0]

Номера в объекте с интерфейсом Map у этого элемента всё равно нет.
ребят, я с вас балдею :D
то что вы не в состоянии обратится к паре по номеру, потому что вам метода такого не написали, говорит о вашем неумении писать код, которого вам не предоставили.

да, а насчет пыха
открываем phpfiddle.org
вбиваем
$a = array(’z’ => ’zzz’);
$a[’a’] = ’aaa’;
$a[0] = ’000′;
echo reset($a);

смотрим на ответ, и продолжаем рассказывать что код работает неправильно.

впрочем и для Set можно получить первый элемент, вызвав toArray()[0]

Вызов toArray()[0] даст первый элемент из промежуточного массива, не из Set.

то что вы не в состоянии обратится к паре по номеру, потому что вам метода такого не написали, говорит о вашем неумении писать код

Интерфейсы, UB, не, не слышали.

смотрим на ответ, и продолжаем рассказывать что код работает неправильно.

Ну и это к чему было? Какое утверждение там надо видеть?

Вызов toArray()[0] даст первый элемент из промежуточного массива, не из Set.
то есть этого значения в Set не существует?

или вы решили о коте Шредингера порассуждать?
хорошо, тоже тема:
а существуют ли в Map значения в Set до вызова entrySet()?

Интерфейсы, UB, не, не слышали.
что — интерфейсы?
я круче могу вам ответить — фабрика абстрактных прокси классов, ёпта! не, не слышали?
Ну и это к чему было?
да так, ни к чему. перечитывать с сначала все равно не будете.
то есть этого значения в Set не существует?

Значение существует, номер («первый») — нет. Из Set’а выбирается «какой-то» элемент.

Ok, как вы определяете «первый»?
Скажем, я вам даю пустой Set. Какую-то имплементацию, вы не знаете какую. Загоните туда 10 одинаковых белых шариков. Внутри Set’а, поставьте чёрную точку на том шарике, который вы считаете «первым». Как выбрать шарик с чёрной точкой из Set’а?

Ok, как вы определяете «первый»?
уже отвечал:
первый это тот который вернется при первом вызове метода итератора.
Внутри Set’а, поставьте чёрную точку на том шарике, который вы считаете «первым».
этот шарик станет шариком с черной точкой, а не первым.
Как выбрать шарик с чёрной точкой из Set’а?
можно тупым перебором, сравнивая — шарик с черной точкой или нет
можно — отсортировав коллекцию по признаку наличия черной точки так, чтобы эти шарики оказались в начале или конце упорядоченной по указанному признаку последовательности.

но, выбрать шарик с чёрной точкой и выбрать какой-то шарик, или первый шарик — это разные задачи.

первый это тот который вернется при первом вызове метода итератора.

Вызвали метод, получили итератор, поставили точку. Выбросили итератор. Вызвали метод ещё раз, получили другой итератор. Без противоречий с интерфейсом Set, итератор указывает на шарик без точки. Какой шарик первый для этого Set’а?

этот шарик станет шариком с черной точкой, а не первым.

Ok, в исходной фразе («достать первый шарик из Set’а») мысленно замените ваше слово «первый» на слово «произвольный». Смысл фразы изменился? Если нет, у вас очень странное понимание слова «первый». Если да, в чём разница между «первым» и «произвольным»?

Если нет, у вас очень странное понимание слова «первый».
да, у меня странное. оно такое же как в статье на вики в определении последовательности и в толковом словаре русского языка.
это конечно очень странно....
Какой шарик первый для этого Set’а?
первый — это тот кто будет получен первым.

мне еще сколько раз нужно написать эту фразу чтоб до вас дошло?

Просто замените слово первый — первый попавшийся. Это в корне все меняет

Просто замените слово первый — первый попавшийся
а можно еще первый заменить на последний.
а потом последний на случайный.
а случайный — на розовый!

как все тогда изменится в корне!

Просто первый попавшийся правильное название того что вы получаете

Просто первый попавшийся правильное название того что вы получаете
а когда у нас коллекция отсортирована по известному нам правилу — то первым будет НЕ первый попавшийся?

Тогда вы скажите ПЕРВЫЙ.
Просто поймите, когда множества не упорядочено, хотя бы по порядку вставки, слово первый элемент не применимо.
Разные кейсы — разное название.

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

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

«не надо приумножать сущностей без надобности»

первый — это тот кто будет получен первым.

Можно на него в Set’е показать, *до* того как он будет получен? Если нет, почему «первый» а не «произвольный»?

ср.: «первый вызов метода итератора возвращает произвольный элемент Set’а».

Если нет, почему «первый» а не «произвольный»?
потому что вызов метода итератора — первый и произвольный — не одно и тоже.
первый вызов метода итератора возвращает произвольный элемент
то есть, каждый итератор, полученный у одного и того же Set, будет первым вызовом возвращать произвольный, то есть случайный элемент?
потому что вызов метода итератора — первый и произвольный — не одно и тоже.

Итератора! Не Set’а. С чего разговор и начался.

У каждого отдельно взятого итератора есть первый элемент. И первый вызов != произвольный. У Set’а нет первого элемента, и нет первого итератора. Первый вызов == произвольный.

Итератора! Не Set’а.
конечно. а кого еще? если мне надо последовательно, то есть один за другим нечто извлечь — то я буду использовать итератор.
У каждого отдельно взятого итератора есть первый элемент.
замечательно то как! а мне другого поведения и не нужно было.
Первый вызов == произвольный.
хренась. это как?
я делаю подряд 6 вызовов. и вы мне говорите что результат первого вызова совпадает с результатом вызова под номером который я получил бросанием кубика?
я делаю подряд 6 вызовов

6 вызовов values(). Получаете 6 итераторов, соотвественно 6 последовательностей элементов Set’а. Никакой зависимости между последовательностями нет — они произвольные. Первый элемент каждой последовательности будет произвольным элементом Set’а.

замечательно то как! а мне другого поведения и не нужно было.

Первый где — в коллекции значений.
Вы получаете первый элемент произвольного итератора = произвольный элемент коллекции (Set’а).

Желаю вам удачи в этом споре, лично я не виже как еще эту мысль объяснить, может у вас получится

6 вызовов values().
не надо телепатировать.
шесть вызовов next.
одним и едниственным values() я уже получил множество значений. зачем мне его получать шесть раз?
Вы получаете первый элемент произвольного итератора = произвольный элемент коллекции
получил в первый раз, и назвал его «Первым». второй раз дернул итератор и назвал Вторым. и т.д.

вы никогда не встречали кода:
var i = 1;
foreach () {
...
++i
}
?

подумалось, а может вам задачки стоит решить

О, а можна я? :)

1. Вы участвуете в соревнованиях и обогнали бегуна, занимающего вторую позицию. Какую позицию вы теперь занимаете?

Залежить від того чи ми з тим бігуном приймаємо участь в одних і тих же змаганнях. А то може він другу позицію в списку Форбс займає і особливо радіти перегнавши його не варто. Ну і нюанси такі що той бігун міг вже фінішувати і просто трусцею охолоджуватися після фінішу, або у нас естафета і мою команду вже обігнали на пару кіл, або роздільний старт був і той бігун фінішував пізніше за мене...

Если я правильно понял как работает reset($arr) и он и правда меняет позицию «внутреннего итератора», то просто так его использовать для получения первого элемента странно =) никто ж не гарантирует, что этим внутренним итератором не пользуется кто-то выше по иерархии вызовов.

Вариант с
foreach()
{
break;
}
выглядит интереснее =)

А кто вам гарантирует что вас не собьет авто на переходе? Что ж вы по нем ходите, странно как-то...

А как получить первый элемент массива в случае, когда нельзя сбрасывать его внутренний итератор?

добрался наконец до компа, проверил одну догадку. про этот итератор.
оказалось таки да.

итак:
что выведет этот код?

$aaa = [0, 1,2,3,4,5,6];
reset($aaa);

function fff($bbb) {
echo reset($bbb);
}

echo next($aaa), next($aaa), next($aaa);
fff($aaa);
echo current($aaa), next($aaa);

проверьте свой ответ на phpfiddle.org

риторический вопрос — почему неучи падки блистать своим незнанием с видом уедателей?

когда нельзя сбрасывать его внутренний итератор?
а КОГДА низя?
и ПОЧЕМУ — низя?

Наверное большие массивы передавать копией в параметры может быть не самой хорошей идеей?

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

По тем же причинам почему в с++ есть константные методы и константность типов.

Я правильно понял, что для получения первого элемента из массива вы предлагаете скопировать массив? Вы бы такой ответ дали на собеседовании?

Наверное большие массивы передавать копией в параметры
то есть вы в не в курсе как передаются массивы в функции php.
Я правильно понял, что для получения первого элемента из массива вы предлагаете скопировать массив?
то есть вы не знаете php но решили кое-что пояснить о нем?
Вы бы такой ответ дали на собеседовании?
за такой, последний ответ на собеседовании я бы поставил 1цу.

учитывая еще и сигнатуру
reset ( array &$array )
....

теоретически можно было бы обсудить нюансы...
например что ссылка в php это не указатель на область памяти.

но смысл?

function fff($bbb) {
echo reset($bbb);
}
Вот здесь у вас копирование массива, разве нет? Соответственно, если будете тут передавать массив по ссылке, то функция fff начнет влиять на результат вашей программы.

кстати, проверил еще одну догадку.
и таки да:

что выведет этот код?

$aaa = [0, 1,2,3,4,5,6];

foreach($aaa as $a) {
echo $a;
if ($a % 2) {
foreach($aaa as $b) {
echo ’i’, $b;
}
}
}

см php.net/...ol-structures.foreach.php

т.е.
Вариант с
foreach()

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

глубокое ж было замечание:


он и правда меняет позицию «внутреннего итератора», то просто так его использовать для получения первого элемента странно =) никто ж не гарантирует, что этим внутренним итератором не пользуется кто-то выше по иерархии вызовов.

Вариант с
foreach()
{
break;
}
выглядит интереснее =)

я так сразу и ощутил эту «глубину», поэтому и взялся ответить :)

foreach в разных версиях php работает по разному. В 5.6.18 такое отрабатывает как и ожидается
$a = array(1, 2);
foreach($a as $d)
{
foreach($a as $b)
{
echo reset($a)."
«;
echo $d.» «.$b.»
";
}
}

и выводит:
1
1 1
1
1 2
1
2 1
1
2 2

при этом foreach меняет внутренний итератор массива, но сам цикл foreach от этого итератора не зависит.

Про PHP вообще ничего не могу сказать, но мне Java импонирует тем, что не нужно заморачиваться о low level issues (хотя C/C++ учил в универе), хотя, если взять ту же concurrency, то без этих заморочек ее вообще трудно понять.

Вопрос нужный. Другое дело я бы его формулировал слехка иначе, например «как в уме посчитать sizeof класса» , как-то так; потом в ходе дискуссии дошли бы и до виртуальных функций с таблицами, и до объектов размером вроде бы ноль и пр. и пр. :8)

А Head of Department проводит собеседования?)

Если хоцца знать — то конечно. И я кстате не всегда им был, и сейчас не хед; а в бытность хедом я собеседовал практически всех (кроме джуниоров) кто шел в деп, иногда по 3-4 чела в день. По той простой причине что принимал final decision — брать человека в деп на работу или нет.

"как в уме посчитать sizeof класса"
Так для класса, а также для элементов могут быть заданы разные параметры упаковки и выравнивания: #pragma pack, __declspec align.

Лучше начинать с полиморфизма. А sizeof — это вопрос больше про выравнивание данных и в уме посчитать sizeof класса не так-то и просто. Например, даже для таких простых структур struct A {char a1; int a2, char a3}; и struct B {char a1; char a3; int a2}, sizeof вернет разные значения в дефолтных настройках GCC или VS.

Не думаю, у полиморфизма только словестное определение простое :8), дальше углубляясь в его виды — у-у-у-у... :) Между тем, я имел в виду не ответ типа «28», а примерно то, что изложено вот тут: habrahabr.ru/post/117996 , п.9 и комменты.
Объясню также почему вопрос про vtable считаю важным. Во-первых, программер должен осознанно пользоваться доступным ему инструментарием, в т.ч. виртуальными функциями, и не путать их с одноименными, но не виртуальными функциями. Понимать это куда легче, если знать, каким образом работает механизм vtable. Далее по ходу собеседования сюда лехко подключаецца вопрос об абстрактных классах, при желании — разница между ними и интерфейсами. А еще vtable интересна тем, что нередко вышеупомянутый sizeof экземпляра класса из указателя ее одной и состоит. А еще интересен вопрос, каков размер и как адресуются в памяти классы у которых нет vtable, виртуального наследования и нет членов-переменных, и это уже вопрос чиста стандарта С++.
Вторая очень важная фича знания и понимания про vtable — это «хакерские» вопросы на тех же собеседованиях, типа этого ru.stackoverflow.com/...-к-приватным-полям-класса . Мое твердое убеждение: программер должен четко понимать, почему предлагаемые там затычки доступа к членам через адрес класса — это таки затычки, абсолютно недопустимые в коммерческой программе.
Десь так, не перенапрягайтесь. Всех с Новым Годом!

Вопрос с полиморфизмом хорош тем, что поговорить можно о многих вещах. Начиная проектрованием и заканчивая нюансами языка. И в общем-то, достаточно быстро становится ясен уровень кандидата. Но тема непростая, соглашусь. А вот зачем спрашивать про размер пустого класса, я не знаю, разве что чтобы завалить кандидата. Какого ответа вы ждете от С++ программиста на вопрос о различии интерфейсов и абстрактный классов? В С++, в отличии от С#, Java, нет различия на уровне языка между интерфейсами и абстрактными классами. Поэтому интересно, какого ответа ожидаете.

А вот зачем спрашивать про размер пустого класса, я не знаю, разве что чтобы завалить кандидата.
Это вопрос понимания стандарта С++ (объектов нулевой длинны быть не может, но они кагбе есть, и ктовинават), перечитайте выше плз. А если бы я ипанулссо и хотел «завалить» кандидатов, я бы спрашивал «как хакерскими методами добраться до приватного члена класса», опять-таки см. вышее. Я постарался обЪяснить, что для меня вопрос о размере класса (точнее, из чего он составляется) важен еще и потому, чтобы подобные затычки в коде никогда не появлялись.
В конце концов, я же не призываю Вас делать то же самое; где-то в соседнем посте я писал, что исхожу из того, что интервьюер, кроме общего разговора о жизни в С++, учитывает все-таки потребности конкретного пректа, куда идет кандидат. Важен полиморфизм — да на здоровье.
Какого ответа вы ждете от С++ программиста на вопрос о различии интерфейсов и абстрактный классов?
Правильного и обдуманного, «нет различия» не катит и опровергаецца
В С++, в отличии от С#, Java, нет различия на уровне языка между интерфейсами и абстрактными классами
Та ну :) ? нет специального словечка (у MS есть), и что с того? Хорошо, давайте считать это вопросом по ООП. Программеры привыкли к интерфейсам и реализовывают их теми средствам, которые доступны — уважаемые аццы-основатели плюсов пока отмазываюЦЦа именно этим, внутренней мощью языка С++. Да, конечно, можно сказать: интерфейс в С++ - это частный случай абстрактного класса, но никак не наоборот. Абстрактный класс остается классом, т.е. в нем может присутствовать реализация, и если кандидат скажет только это, уже хорошо. Главное то, что (и как) класс наследуеЦЦа, интерфейс — реализовывается, причем реализовываются все его методы. Т.е. абстрактный класс — это все-таки средство повторного использования кода, интерфейс — это обязательство, что обЪект будет гарантированно реализовывать заранее известный набор методов. Т.о. идеологически это вполне разные весчи,.. вот и интересно, когда кандидат, выстраивая архетектуру классов, воспользуется молотком, а когда отверткой и плоскогубцами ;)
А если бы я ипанулссо и хотел «завалить» кандидатов, я бы спрашивал «как хакерскими методами добраться до приватного члена класса», опять-таки см. вышее.
Кстати, почитал в той статье на хабаре п.12 habrahabr.ru/post/117996 там вообще обратили внимание на какой-то юмор в стандарте. Никаких хакерских методов не надо, если класс выведен с приватным или защищённым модификатором. Достаточно только указатель на объект дочернего класса привести к базовому классу, и совершенно легально получить доступ к закрытым элементам, без всякого хака. Ну и на практике приватное или защищённое наследование никогда не юзается.
Программеры привыкли к интерфейсам и реализовывают их теми средствам, которые доступны — уважаемые аццы-основатели плюсов пока отмазываюЦЦа именно этим, внутренней мощью языка С++
А ещё аццы-основатели упорно отмазываются от статических конструкторов/деструкторов. Статические данные в классах есть, а статических конструкторов нет. Ещё при всей мощи, в C++ отсутствуют коротины на уровне языка — в принципе.
В С++, в отличии от С#, Java, нет различия на уровне языка между интерфейсами и абстрактными класами
Та ну :) ? нет специального словечка (у MS есть), и что с того?

Ох який прекрасний баг я не так давно ловив в старому коді де використовувався MS’овський __interface: навіть якщо усі методи інтерфейса прописати явно як virtual у класа який реалізує цей інтерфейс деструктор не стане віртуальним. Ну і відповідно наслідуємо інші класи навіть не маючи гадки що там десь якийсь інтерфейс в корні ієрархії і очікуємо що все буде звільнено як і має бути бо методи ж явно прописані як віртуальні... А потім бігаємо по офісу з криками «ми знайшли баг в компіляторі — деструктор похідного класу не викликається!!11адін-адін» :)

Я не думаю, что они имели в виду реализацию vtable lookup до мельчайших подробностей во всех деталях. Скорее, имелось в виду, чтоб человек «на пальцах» рассказал в первом приближении, что это и зачем нужно. В любой хорошей книге по C++ эти вещи расписываются.

Вопрос весьма интересен и я бы сам его задал, забавно но авторы ряда книг обходят его сторонной, тем не менее мне кажется стоит представлять что происходит с объектом при мемкопи и как он организован в памяти. Хотя в 90% случаях это и не надо, но очень помогает при разборе коредампа или другой отладки. И как раз это больше стоит знать разработчику на плюсах, а не Ява :) Лезть туда не надо, надо понимать как оно работает.

тупое побайтовое копирование, ничего плохого в большинстве случаях не произойдет, но указатели будут просто скопированы, что может привести к весьма забавным эффектам, например двойной очистки. Безопасней на мой взгляд использовать оператор=, правильно перегруженный. С памятью честно говоря сам хз, у меня только 1.5 месяца опыта С++, но что-то похожее на структуру Си+таблица))) А можно примеры чего это вам такое «знающие» нагавнокодили?

Самое смешное, что после 15+ лет кодинга, из них 2 на C++ я тоже не дам чёткого ответа. Я могу рассказать это ПРОГРАММИСТУ, который сможет отличить void *foo() от void (*foo)()

Но бюрократу нужно именно чтобы ты по памяти произнёс умные слова, которые он прочитал в книжке. Притом именно в той книжке, которую прочитал он, написанной писателем и правленной редактором, чтобы красивше звучало.

По факту таблица виртуальных функций — это таблица виртуальных функций. Что ещё к этому можно добавить? Разве только то, что понятие «виртуальный» — чисто человеческое, в результирующем программном коде этого нет. А есть просто таблица указателей.

СОВАТЬСЯ в эту таблицу столь же геморойно, сколь и опасно. Достаточно просто знать, что она есть. Единственные, кому это таки нужно — системным программистам. Антивирусы, программы для взлома, программы для тестирования на уязвимости, программы для защиты от взлома, обфускаторы. Это крайне узкая специализация, и джунов туда не допускают.

Другими словами, тебя стоило брать независимо от того, знаешь ли ты о её существовании. Всё что тебе нужно знать как ПРИКЛАДНОМУ программисту — это правила кошерной работы с указателями, и бояться как чёрт ладана работать с указателями типа void.

Вот о чём тебя стоило расспросить — так это о множественном наследовании. Этот вопрос настолько краеугольный камень C++, что мне достаточно было бы задать только его, чтобы понять чем ты дышишь. Здесь недостаточно почитать умных книжек, ты их не поймёшь пока в руках не окажется реальная задача. И вот какими словами ты скажешь — расскажет от твоём опыте работы больше, чем часовое собеседование. Если в твоих словах будет хоть оттенок книжного бюрократизма — значит ты не понял с чем имеешь дело и тебе только предстоит наступить на взрослые грабли.

Лучше о виртуальном, как идеальном инструменте отстреливать себе яйца
Вот интересно, кто-нибудь из здесь присутствующих пользуется реально виртуальным наследованием, за исключением интерфейсов? Вот я лично за много лет разработки — не пользовался, и у других в коде не видел.

Пользовался, было в тему.

При чем тут интерфейсы? а.. ну да.. В интерфейсы то собственно я и подмешевал референс каунтинг.

Вообще я не про COM-интерфейсы, а про абстрактные классы без данных в общем случае, ну да ладно... Ну класс, где хранится счётчик ссылок наследуется виртуально, это всё. А теперь уже появились стандартные smart pointers с другой моделью подсчёта, где выводить не надо.

Вообще я не про COM-интерфейсы,
Я тоже.
про абстрактные классы без данных в общем случае
А каким они боком к виртуальному наследованию?

Так а я о чём? Да, механизмы есть. Да, ими можно пользоваться, если без них никак, и готов расплатиться рисками и геморойной отладкой.

Только на собеседовании это — зачем?

Я считаю, что просто собеседование проводил попуас с целью потешить своё ЧСВ, а по факту отшил будущего сотрудника. Дурак тот, кто платит этому человеку деньги за сие действо.

Кроме того реализация таблиц различна даже в разных версиях одного и того же компилятора, уже не говоря о разных.

Зато под юниксами давно её стандартизовали между разными компиляторами и меняют детали реализации один раз во много лет. (И мне пофиг, какой из модулей был собран gcc, icc, clang, open64 или ещё чем-то более экзотическим, и это банально удобно.)

СОВАТЬСЯ в эту таблицу столь же геморойно, сколь и опасно.
Человека не просят СОВАТЬСЯ, его спрашивают WTF
Достаточно просто знать, что она есть.
Ну да ... или она есть, или ее нет, почему и нафига .

Работа программиста — именно в том чтобы соваться. Всё остальное достаточно признать как данность и ЗАБЫТЬ. До тех пор когда (если вообще) понадобится.

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

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

Простой пример: для установки долгосрочных отношений — врать нельзя! Что делает типичный HR на собеседовании? Врёт. У него целый бекграунд заранее приготовленного корпоративного вранья. ИЧСХ, он требует от кандидата тоже врать, и той же самой корпоративной бюрократией. Почему так: бюрократ не делает работу, и кроме красивой лжи о ней знает крайне мало. Результат: бюрократы фильтруют к себе только бюрократов, отбрасывая тех кто умеет и готов работать.

Интервьюеры забывают, что это ОНИ проводят сотни и тысячи собеседований. А большинство соискателей — не чаще одного в два-три года. Интервьюер готовится и знает список вопросов которые задаст, соискатель — знает ответы на сотни тысяч вопросов, касающихся работы. Но нихрена не понимает и не обязан понимать во внутренней кухне HR.

Если транзакционные издержки «благодаря» HR растут для кандидата — они же растут и для компании. HR должен снижать издержки. Если издержки растут — выгнать поганой метлой бюрократов и нанять специалистов, которые издержки снизят!

ШШШаз, момент:

Интервьюер готовится и знает список вопросов которые задаст, соискатель — знает ответы...
— да, ОК, но откуда интервьюер берет этот список хреновой тучи вопросов!? Если заказчик мне сказал, что мы пока не переходим на С++14/17 стандарт, я не буду настаивать на нем на собеседовании. Если виртуальные функции попадаюЦЦа в проекте два раза в год по большим праздникам — скипаем vtable, хсним. Я исхожу из того, что, кроме общих вопросов о жизни в С++, интервьюер спрашивает то, что важно именно для того проекта, куда идет кандидат, а не просто вываливает всю тучу на стол. И тогда мы сужаем ту область совпадения, где живут вопросы, критические для интервьюера и не забытые программером. Кста нащот «забывания» я бы тоже поспорил...
Если транзакционные издержки «благодаря» HR растут для кандидата — они же растут и для компании. HR должен снижать издержки. Если издержки растут — выгнать поганой метлой бюрократов и нанять специалистов
Согласен на 100%, хотя это нелегко сделать :) И Вы еще не упомянули об извечном свойсте бюрократии — плодить и подкармливать себя саму :)
Но учитывайте и обратную сторону медали: если тех-лиду приходится постоянно самому искать кандидатов, разговарить с ними, назначать встречи и рисовать маршруты доезда, самостоятельно постигать психотипы кандидатов ... а не слишком ли дорогой рекрутинг получается в таком случае, не растут ли издержки и в этом случае? не легче ли взять девочку и делегировать часть рутины ей :) ?
Вопщем, истина посередине, и как на меня во многом зависит от СЕО или СHRО, кто заведует такими процессами в компании; точнее, от того, насколько он на все забил.
На самом деле эффективность большинства собеседований — отрицательна. Эта проблема в самой технологии
Да, есть проблема в технологии, о которой Вы говорите, но с отрицательной оценкой я не соглашусь. Начнем с того, что есть же ж еще такая штука как испытательный срок, практически повсеместно; тут уже врать сложно, угу? так вот, моя личная оценка моего личного опыта: час-полтора-два собеседования дают вполне адекватное представление о человеке и специалисте. Навскидку, из примерно полутора сотен специалистов которых я брал на работу за последние 4-5 лет (собеседовал значительно больше), буквально двое или трое не прошли испытательный срок... как-то так. Правда, у меня есть большой недостаток — я не HR и никогда им не был :8)
ИМХО ветка не та для сей дискуссии ...

Если вопрос возникает 2 раза в год, то человек проработавший с ним год — столкнулся с ним уже дважды. Только ведь вопрос был не о виртуальных функциях, а про её таблицу. То есть НИЗКИЙ УРОВЕНЬ реализации. В неё соваться — моветон в принципе.

На собеседовании профессионал может смело задавать вопросы, на которые в 50% случаев подходящий соискатель не знает ответа, но... знает как этот ответ добыть в течение 5 минут. Иными словами, если он в году неделю потратит на добывание таких ответов — это НОРМАЛЬНО для нашей профессии! Мы тратим и больше.

Кстати, ты в HR понимаешь больше, чем 80% представителей этой профессии. Иными словами, тебе они будут вредны. Ведь буквально за 10 минут на каждого — и узнаешь то, ради чего они мурыжат кандидатов месяцами. И как уже упоминал, 3 из 4 нужных людей они отсеивают по принципу случайного генератора.

ИСПЫТАТЕЛЬНЫЙ СРОК находится за пределами компетенции HR, они в него рыло практически не суют. Посему и процент приживаемости огромен. Хотя надо сказать, если бы HR был профессиональным, то процент отсева был бы выше, в районе 10-15%. Почему так: выгоднее попробовать человека, чем гадать. Ведь это не значит держать его месяц, там экспоненциальное распределение — львиная доля неподошедших узнают об этом уже за первые 2-3 дня.

Кстати, среди вылетевших на испытательном — немалая доля тех, кто просто принял другой оффер. По той причине, что:
— HR затянули этап «мывампозвоним», и кандидат не прекратил поиски
— HR тянут с оформлением
— попал не на проект своей компетенции
— не выплатили зарплату, потому что не оформили
— не готово рабочее место
— кандидат обнаружил что ему банально наврали!
Иными словами, без HR этих проблем бы не было ни одной. Просто не было бы людей, у которых есть время на всю эту бюрократию, и где бюрократов нет — простые вопросы решаются очень быстро и незатратно.

Только ведь вопрос был не о виртуальных функциях, а про её таблицу. То есть НИЗКИЙ УРОВЕНЬ реализации. В неё соваться — моветон в принципе.
Я не буду повторяться и говорить что работа программера именно в том и состоит чтобы соваться :) Но в плюсах если есть виртуальная функция, есть и таблица. Буквально на 3-4 страницы вышее я постарался обЪяснить, почему считаю такой вопрос важным, в т.ч. с практической точки зрения.
соискатель не знает ответа, но... знает как этот ответ добыть в течение 5 минут. Иными словами, если он в году неделю потратит на добывание таких ответов — это НОРМАЛЬНО для нашей профессии!
Мало :) Но вааще согласен 100%, именно такое и ищещь на собеседовании.
Кстати, ты в HR понимаешь больше, чем 80% представителей этой профессии.
Явное преувеличение, программеров пси-хологиям, гештальтам и НЛП не учат. Мое к ним отношение — дело другое; я бы запретил.
3 из 4 нужных людей они отсеивают по принципу случайного генератора
Алексей, всі ці неподобства зависят от постановки процесса. Зачастую все начинаецца с благих намерений, и кончаецца вполне привычными родственными и другими половыми связями. Я у себя в депе на два года процесс сумел завести, никакие случайные генераторы не работали, блябуду.
ИСПЫТАТЕЛЬНЫЙ СРОК находится за пределами компетенции HR, они в него рыло практически не суют. Посему и процент приживаемости огромен.
Почему за пределами!? очень даже в пределах. Аднако, у нас в компании должности HR и рекрутеров разделены, и я считаю что это правильно. Кстати, turnover персонала у меня был одним из КПИ.
...По той причине, что:
Вы не указали тут причину, которая уверенно лидирует: кандидат имел на руках более одного офера. Получив предложение от фирмы А на 2К, он идет в фирму В, гордо его демонстрирует, и получает на 200 больше. Как вариант — показывает предложение на своей старой работе и получает прибавку и долгожданный перевод з задолбавшего его проекта на новый. Тут HR-ы ни при чем, бюджет не они устанавливают. Даже скорее наоборот: поскольку в их КПИ часто входит уровень взятых на работу спецов, а уровень этот часто меряеЦЦа входной зряплатой, сами по себе они не склонны экономить на Вашей з-п.
Иными словами, без HR этих проблем бы не было ни одной.
Были бы другие. Это как в анегдоде — “я с утра заправился, залил новое масло, заказал новую зимнюю резину, договорился затонировать боковые стекла... успел бы я все это сделать, если бы у меня не было автомобиля!?” Еще раз — ничего не делается само по себе, их надо постоянно “бить по шапке”, т.е. рассказывать и показывать, что от них требуецца. Это во многом зависит от их начальника. Вам наверно в свое время повезло на старого похуиста или молодую похуисточку :8) Вы все правильно говорили про издержки: нормальный шеф увидит, что эффективнее, и пригласит техспеца на более ранние стадии отбора, либо найдет способ научить HR работать профессионально.

Буду краток: в этой стране попросту нет культуры HR. Психология трудовых отношений — она другая, и рядом не стояла с гештальтами и прочими фенечками. Учитывая, СКОЛЬКО людей занято в трудовых зависимостях, на этом должны специализироваться 5 из 10 психологов. Ещё 4 из 10 — на продажах. Иными словами, ПОЛОВИНА рынка этой профессии не раскрыта вообще.

Зато культура бюрократии этой страны хуже азиатской. В менеджменте так точно. Например — если кандидат честно укажет причину ухода с предыдущей работы, его отсеют с гарантией 200%, ещё и в стоп-лист занесут. Я это специально исследовал — спрашивал людей настоящую причину, а потом рекрутеров какова вероятность найма человека с этим нюансом. НИ ОДИН из сотен не был бы нанят никем, даже на самую низкооплачиваемую работу.

Практически невозможно постигнуть один факт: если у тебя это работает, то как такие простые вещи могут не работать у других? Это примерно как человеку который ни разу в жизни не общался с гос.органам — объяснить что такое «приёмный день вторая пятница месяца в 17-00», при том что рабочий день до 17.

Зависит это только от одной вещи: ОБРАТНАЯ СВЯЗЬ. Если с самого верха не проверяют, как что работает на самом деле (а не по отчёту о проимитированной работе) — оно не будет работать.

Ключевая проблема HR-функции сегодня: они судят по себе. У менеджмента кстати та же проблема: не имеют гуманитарного образования чтобы не только разбираться в РАЗНЫХ людях, но ещё и понимать что эта разница — и даёт выгоду.

PS. Людей которые не ошибаются — нет. Если такой человек есть — значит он не делает ничего полезного, то есть его положительный и отрицательный результат одинаково бесполезны. Самые ценные люди имеют за плечами огромный опыт ошибок. И готовы делать следующие, притом открыто и в рамках управляемого риска. Покажи мне хоть одного HR-а, который готов взять таких людей. И покажи хоть одного, который признает что ошибается сам. А среднюю частоту ошибок я уже называл — 3 из 4 нужных кандидатов выбрасывается. Притом самые ценные, которые дадут команде новые компетенции — выбрасываются практически всегда, и устраиваются в основном по знакомству.

Мне аж интересно стало, что это за настоящая причина из-за которой не берут на работу?

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

Мне аж интересно стало, что это за настоящая причина из-за которой не берут на работу?

Ну например когда 2 директора налажали — один по дури, а второй исподтишка облизав попередныка и последовав советам повторил те же самые ошибки,
при этом убил проект ( успешный стартап ), влетел на сумму в четверть ляма и потерял команду разработчиков.

Но признаться что тупанули ( да еще по какой причине ! )- не могут, ибо директорский статус теряет ликвидность. Поэтому творят очередную безумную аферу — синхронно брешут, пробуя нагадить разработчику.

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

Однако в долгосрочной перспективе абсолютно бесполезен и вреден уже для самой компании. Ведь гигиена и сохранность гланд директора — это его личная забота, а не сотрудника. Тем более переделать «за бесплатно» чтобы «спасти всю команду» тоже не вариант.

Вообщем таковы реалии украинского IT-аутсорсинга. Кроме того, наблюдаю с ужасом телевизионные интервью, в которых «реформаторы от IT» обещают научить украинцев правильно жить. Ибо таких людей в нормальных странах близко к гос.органам подпускать нельзя, а менталитет — он на всю жизнь ....

Тяжело спорить с опщими выводами ... разве что не соглашусь что «3 из 4 нужных кандидатов выбрасывается» — думаю на практике там твердые 50%: или выбрасываюцца, или не выбрасываюцца.

Я был гораздо оптимистичнее, думал ну максимум 1 из 20. А когда увидел цифры первый раз прозрел, и решил перепроверить, лично провести исследование. Так вот, есть малая доля профессионалов — они моментально хватают нужных людей и не отпустят, они же быстро и жёстко отсекают надеящихся на авось.

А есть целая отрасль — которая работает исключительно по мифам. Поверить на слово тут сложно, как минимум поговори лично хотя бы с 10-20 обычными рекрутерами не из твоей компании и не твоих знакомых. Это целая религия и 0% научных знаний в ней, сплошные авторитетные мнения. По уровню упоротости переплёвывает любую религию, кроме разве что веры патологических игроманов в удачу.

В основе этой веры — классический механизм формирования суеверий: люди автоматически запоминают действия, приведшие к положительному результату. Но только научный подход даёт верное предсказание — он требует анализировать и неудачи тоже. Разве HR хоть раз были наказаны за необоснованные отказы. Нет! За отказ наказания нет.

Да говорил, в т.ч. и как соискатель. В т.ч. с индусами и латиносами. В Вашем изложении сие звучит как элемент теории заговора; по-моему, все гораздо проще — элементарная дурь. Истоки: в университетах этому не учат — потому и уровень науки нулевой, потому 90% в этой «отрасли» — девачки с педагогических и т.п. факультетов, которые по разным причинам не пошли работать по специальностям, а вспомнили, что есть такая классная и модная теперь профессия, а у них записано в дипломе «[детский/геронто-/домашних животных и пр.] психолог». И их конечно вдохновляет мысль, что театр начинается с вешалки, а вход в компанию — с нее, красавицы и умницы. Лечицца достаточно легко — песдюлями, но нужен «доктор». Сопсно как везде, и в программировании тоже: сначала несколько месяцев втыкаеш во все, что делает твой джун, потом он делает релиз под Твоим присмотром, и только через полгода можешь дать задание и забыть про плотный контроль.

Но только научный подход даёт верное предсказание — он требует анализировать и неудачи тоже. Разве HR хоть раз были наказаны за необоснованные отказы. Нет!
Почему Вы обвиняете их только в отказах? Как на меня, грех, когда в компанию надо взять сразу 40 спецов по Silverlight :) , и в результате проходят хто попало, лишь бы отличал сие от Moonlight, не меньший ... В них не прошито «отказывать», скорее — «делай как я сказал, а то вылетишь с такого прекрасного и насиженного места» ... и снова возвращаемся к тому чифу, который курирует HR-ов и рекрутеров.

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

Лягушкам только образования не хватает, а так они на всё способны! ©Марк Твен

Насчёт спецов «средних по больнице» — согласен. Это реальный мир, я ж не говорю брать всех. Но так чтобы процент отсева на испытательном сроке был около 10%, возможно до 15% у сложно тестируемых категорий. Это куда дешевле, чем фильтровать по косвенным признакам.

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

Почему так: Мы тупо живём не в той стране, где есть культура трудовых отношений. Попробуй к примеру в Германии специально подгадить бывшему сотруднику — так он в суд подаст и прав будет. У нас же >70% о своих бывших отзываются плохо, и в 100% плохо — если разрыв отношений произошёл по вине работодателя. Даже если человек 8 лет проработал и всё устраивало — а тут он «внезапно» становится конфликтным, интриганом, работу прогуливает, и перегаром воняет. Оказалось бы что и проституток приводит, если бы я спросить догадался.

Ничего с этой культурой сделать нельзя. Лишь расставить правильные акценты: в этой стране людей нужно ПРОВЕРЯТЬ по ним самим — всегда, когда это возможно. Косвенные признаки из западных учебников у нас не работают.

PS. Умение писать резюме — вообще не должно быть признаком. За отсев по «правильности» оформления резюме нужно сажать на кол у входа в здание. Единственно правильное решение — анкетировать самим, и анкета должна быть короткой. Суть вопросов только одна: сможет ли работать: да/нет.

Но в плюсах если есть виртуальная функция, есть и таблица.

Или несколько таблиц (при множественном наследовании). Но надо понимать, что это только оптимизация. А вот что важнее, мне кажется, это порядок применения этих таблиц в цепочке конструкторов (тут весьма интересные грабли, и отличия от родственных языков).

Я у себя в депе на два года процесс сумел завести,

О каком депо речь? И что там специфического для программиста?

Дружище, мог бы и загуглить на тему, какой же первый вопрос задают на плюсовых собесах, перед тем, как туда идти :)

С наступающим тебя, мудрости и пронырливости в Новом году!

Вот те кто задаёт вопросы и гуглят: «вопросы для собеседования». Вместо того чтобы зайти на Stackoverflow и посмотреть реальные рабочие вопросы, которые нужны человеку для умения писать хороший код. Банально топ по лайкам. Да хотя бы взяли FAQ и почитали.

Мне кажется что это «базовое понятие» для какого то Java разработчика, но для плюсов это уже тонкости.
а ти остряк

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

Кстати говоря, джавистов о ней никогда не спрашивают. Хотя таблица всё там же, и пользуются ей точно так же. А всё почему? Да потому что в книжках модных об этом не пишут, а пишут про другое. Хотя пакет sun.misc.unsafe существует, никуда не девался и не денется, система на нём завязана мёртво.

Это самое простое, на чем не валят, а проверяют осилил ли человек хотя бы 20% книги Страуструпа

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

Категорически не согласен. Я осваивал C++ в первый раз именно по книге Страуструпа, и это оказалось очень эффективно. Просто надо читать его не так, как читают книги из серии «для полных чайников за 21 день», а вдумываться в каждую деталь, там нет лишних деталей.

Если это НЕ ПЕРВЫЙ язык — да, возможно. Но учиться программировать по ним не выйдет. Там допущена ошибка многих книг «от эксперта»: эксперт рассказывая 1% знаний, опирается на свои оставшиеся 99% знаний. Читатель же не умеет читать мысли.

Чего нет: быстро собираемых конструкций. То есть чтобы понять одну страницу, ещё страниц 40 держать в памяти, и ещё страниц 500 знать из других источников. Хотя можно было всё нужное вписать в одну страницу, не боясь повторений.

Но учиться программировать по ним не выйдет. Там допущена ошибка многих книг «от эксперта»:

Это не ошибка. Цитирую предисловие:

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

Это был намеренный шаг. Для обучения с нуля (если оно вообще имеет смысл начинать с C++, в чём я очень сомневаюсь) есть другие книги.

Чего нет: быстро собираемых конструкций. То есть чтобы понять одну страницу, ещё страниц 40 держать в памяти, и ещё страниц 500 знать из других источников. Хотя можно было всё нужное вписать в одну страницу, не боясь повторений.

К этому хотелось бы примера. Как для меня, всё училось достаточно просто, быстро и линейно. Тут надо уточнить, что это было в 1992 году и по 2-му изданию, а не более поздним. Но поздние, как мне кажется, расширили его, не ломая совместимость.

это было в 1992 году и по 2-му изданию
Вот именно. Более поздние сделали куда более неудобоворимым для добычи НОВОЙ информации. Конструктор знаний собирается от малого к большему.

Когда чтобы собрать базовое знание нужно отфильтровать тонну бесполезного на данном этапе хлама, оно тупо становится несобираемым. Хотя тем кто УЖЕ знает — кажется что написано всё правильно и в удобной форме.

Это проблема львиной доли книг от экспертов.

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

...

Мне кажется что это «базовое понятие»
Ох зря ты на счет этой таблицы так зря....
Вообщем то реализация всего полиморфизма классов С++ вокруг нее крутиться.

И вероятнее всего не столкнёшься. Потому что это низкоуровневое программирование. С тем же успехом тебя можно спросить ассемблер.

Применять эти навыки в прикладном программировании — опасно. Хотя бы потому, что весь контроль исполнения ложится на тебя, а не на компилятор. И потом уже в готовом коде это всё вылезет кишками наружу, вплоть до доступа в операционку с высокими привилегиями через твой дырявый софт.

полиморфизма

Такие тонкости, как полиморфизм, тоже нужно знать для успешного собеседования?

Я дуже надіюся, що це був сарказм.

О том что он существует и как применяется — спрашивать надо. Нужно спрашивать как его программировать. Но задавать вопросы джуну о внутреннем механизме — всё равно что расспрашивать шестиклассницу о зачатии.

Львиная доля программистов на C++ никогда не притронется ко внутреннему механизму полиморфизма. Хотя бы потому, что это небезопасно — компилятор его не сможет проконтролировать, вся надежда что человек который пишет код — знает что делает. И потом это «знает» вылазит наружу уязвимостями, позволяющими пользовательским данным порулить операционкой. Притом даже у матёрых программеров, в стабильном коде с миллионами инстансов по миру.

О том что он существует и как применяется — спрашивать надо. Нужно спрашивать как его программировать. Но задавать вопросы джуну о внутреннем механизме — всё равно что расспрашивать шестиклассницу о зачатии.

Какой нафиг внутренний механизм, какие нафиг доступы порулить операционкой? Кто даст junior писать драйвер(а)? Я уже втрой раз это от Вас читаю, простите не удержался...

Всё что нужно значть что бы ответить на этот вопрос это:
— порядок конструирования в С++ и как логическое и неизбежное следствие этого:
— почему виртуальные функции не работают в конструкторах

Всё! Это и будет ответом на вопрос что такое VTBL. Блин...

Вот эти 2 вопроса именно в такой форме и нужно задавать на собеседовании. А не про таблицу.

PS. Насчёт «кто даст» — я тоже в молодости так думал. Но опыт. Я такое видел в руках у джунов, что чуть фейспалмом не убился декомпилируя код продакшена.
Я больше скажу — им и нужно давать. Да, придётся обучить. Но для написания низкого уровня нужно время, дохрена времени, и на обезьянью работу. Время джунов просто дешевле.

Мне кажется что это «базовое понятие» для какого то Java разработчика, но для плюсов это уже тонкости.

Это базовое понятие C++ ABI многих (всех?) компиляторов

Объяснил бы исходя из понимания, в стандарте ISO нет определения, как и некоторых других вещей, например модификаторов. Каждый класс, содержащий хотябы 1 виртуальную функцию, имеет таблицу адресов этих виртуальных функций, общую для всех членов каласса, а каждый член класса содержит указатель на таблицу своего класса.

Погугли. Это очень простое понятие, которое тебе никогда не понадобится. Более плотно рассматривается в курсе системного программного обеспечения, в том числе такого которое умеет работать вне операционки.

Не те книжки читал, значит. Стивен Прата прекрасно об этом расписывал. Без тонкостей (тонкости у каждого компилятора будут свои), но в общем главу из его книги прочитать было бы достаточно, чтобы разобраться, что такое vtable и зачем оно нужно.

Снимаю с полки книгу Страуструпа с желтыми страницами.
Открываю предметный указатель.
Нахожу тему аж в обзорной второй главе на странице 73 даже с иллюстрирующим рисунком

Для C++ это даже «более базово», чем для Java.

Для джунов — да. И даже для мидлов. Лезть в эту таблицу раньше 4 лет кодинга не рекомендуется. Хотя бы потому, что там НЕ ВСЁ ОЧЕВИДНО, и компилятор C++ позволяет много чего интересного считая что программист ЗНАЕТ что он делает.

Знать и суметь объяснить книжно-бюрократическим языком — две большие разницы. Вообще-то эти фичи были созданы специально, чтобы НЕ задумываться об их существовании.

Слово «виртуальный» кстати говоря там лишнее. А вот таблиц, если лезть в дебри работы машинного кода, там далеко не одна, их там туева хуча разных. Там практически всё таблицы.

Жаль, что нельзя просто взять и прикрепить этот ответ вверху.

Підписатись на коментарі