Какие вопросы задавать на интервью

[shokoladnitsaa]

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

Не более странно чем рассуждения о величии Шишкина от брайтановского бича Но в отличии от вас ценность статьи подтверждена научным руководителем и приемной комиссией

Наверное, той же комиссией, к-рая подтвердила неполноценность Довлатова

[blanko27]

Главная задача интервью - определить с какими социальными меньшинствами претендент себя идентифицирует. Наймете случайно мужика, да еще окажется неполиткорректным белым супрематистом - на форум потом жаловаться не бегайте, так вам и надо!
А то C++ какой-то, детский сад, понимаешь...

[rtogan]

Ну нам нужен чисто "шарповщик" Честно говоря нам самим неинтересно почему в шарпе так а в С++ так а вот для интереса приведите пример что Вы спрашиваете в этой области и зачем?

Почему в плюсы не добавили интерфейсы, как в шарпе? Зачем в шарпе есть ключевое слово virtual, если джава без него прекрасно обходится.
Тут важен не ответ, а вообще отношение к работе, задумывался ли человек над такими вещами, любит ли свою работу или нет?
Если работает на отвали - ответом будет "а нахрена это надо", если нет - воспримет вопрос с интересом и скорее всего ответит, т.к. вопросы простые

А что, C# программист обязательно должен знать джаву? Кроме того, не задумывались ли вы о том, что разные люди по-разному определяют критерии оценки отношения программиста (и не только) работе?

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

Ну понятно, судите по себе и считаете, что все должны мыслить/делать как вы. Makes sense.

[Мальчик-Одуванчик]

Почему в плюсы не добавили интерфейсы, как в шарпе?

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

Абсолютно нет. Абстрактные классы есть и в шарпе. Что бы привести к нему, надо быть от него наследованным, а для приведения к интерфейсу - нет.
Правильный ответ тут в том, что причина в том, что в шарпе есть boxing/unboxing и поэтому к интерфейсу можно приводить value types, а в плюсах нет этого. А нет потому что нет сборщика мусора

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

[OtherSide]

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

Ключевое слово interface есть или что?

[Мальчик-Одуванчик]

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

Ключевое слово interface есть или что?

В лексике С++ именно этого слова не имеется, но имеется другое - virtual, из которого выводится и понятие интерфейса.
Хотя изначально Ваш вопрос относился к семантике - странно что Вы перевели его на синтаксис.

[M. Ridcully]

Ну понятно, судите по себе и считаете, что все должны мыслить/делать как вы. Makes sense.

Ну в-принципе, не смотря на вашу иронию, такой подход действительно makes sense. Им же вместе работать. Нужен culture fit, как тут говорят.

В моей последней компании в Москве подобная hiring policy озвучиавлась примерно так - "Мы всех берём. Мудаков только не берём".

[OtherSide]

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

Ключевое слово interface есть или что?

В лексике С++ именно этого слова не имеется, но имеется другое - virtual, из которого выводится и понятие интерфейса.
Хотя изначально Ваш вопрос относился к семантике - странно что Вы перевели его на синтаксис.

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

[Мальчик-Одуванчик]

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

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

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

[OtherSide]

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

[M. Ridcully]

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

Очень сильно подозреваю (давно очень с C# не работал), что в C# - точнее, в CLR runtime - эти методы, имплементирующие интерфейс, всё равно виртуальные, даже если на уровне C# вы их таковыми и не помечаете.
Так что абсолютно то же самое.

[OtherSide]

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

Очень сильно подозреваю (давно очень с C# не работал), что в C# - точнее, в CLR runtime - эти методы, имплементирующие интерфейс, всё равно виртуальные, даже если на уровне C# вы их таковыми и не помечаете.
Так что абсолютно то же самое.

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

[M. Ridcully]

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

Очень сильно подозреваю (давно очень с C# не работал), что в C# - точнее, в CLR runtime - эти методы, имплементирующие интерфейс, всё равно виртуальные, даже если на уровне C# вы их таковыми и не помечаете.
Так что абсолютно то же самое.

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

Нельзя в общем случае, конечно же.
Простейший пример - полиморфная коллекция.

[OtherSide]

Нельзя в общем случае, конечно же.
Простейший пример - полиморфная коллекция.

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

[M. Ridcully]

Нельзя в общем случае, конечно же.
Простейший пример - полиморфная коллекция.

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

Либо я вас не понял, либо вы какую-то фигню написали.

А вообще, не гадайте, поищите, как интерфейсы реализованы на уровне CLR runtime.

[Мальчик-Одуванчик]

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

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

Резюмируя: Вопрос об отсутствии в плюсах интерфейса некорректный. Он там имеется и средства самого языка достаточно выразительны чтобы обойтись без дополнительной лексемы.

[Мальчик-Одуванчик]

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

[OtherSide]

Вот написал тестирующий код. На моем компьютере результат:

interface function:6814992 ticks virtual function:20340724 ticks, virtual slower than interface: 2.984703 times

В 3 раза медленней. Если бы интерфейс автоматически помечал наследуемые методы как виртуальные, результат был бы одинаковый.

using System;


namespace ConsoleApp1
{

interface ISlower
{
void func1();
}

class justClass: ISlower
{
int a;
int b;

public void func1()
{
a = 0;
}

virtual public void func2()
{
a = 0;
}
}

class Program
{
static void Main(string[] args)
{

var j = new justClass();
long d1;

d1 = DateTime.Now.Ticks;
for (int i =0; i < 1000000000;i++)
j.func1();

long d2 = DateTime.Now.Ticks - d1;

d1 = DateTime.Now.Ticks;
for (int i = 0; i < 1000000000; i++)
j.func2();

long d3 = DateTime.Now.Ticks - d1;

Console.WriteLine("interface function:{0} ticks virtual function:{1} ticks, virtual slower than interface: {2} times ", d2,d3, 1.0f*d3/d2);


while (true) ;
}
}
}

[OtherSide]

Скорее всего внутри языка реализация интерфейса следующая: при приведении типов хранит в себе указатель на объект и собственную VMT, которую заполняет из наследника.
В отличии от наследника абстрактного класса, где указатели на методы хранятся в VMT всегда

[M. Ridcully]

Мне лень глубоко копать, как там в .NET что реализовано, но вот нарыл статью (достаточно старую) - https://github.com/dotnet/coreclr/blob/ ... ispatch.md - и в ней вот такую фразу:

This may be useful if ever the runtime wants to support the implementation of interfaces with non-virtual methods.

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

А по поводу вашего кода - не знаю насчёт C#, но С++ компилятор бы вообще тривиально оптимизировал бы и сделал эти функции - по крайней мере, func2(), а скорее всего и func1() - невиртуальными.

[OtherSide]

Мне лень глубоко копать, как там в .NET что реализовано, но вот нарыл статью (достаточно старую) - https://github.com/dotnet/coreclr/blob/ ... ispatch.md - и в ней вот такую фразу:

This may be useful if ever the runtime wants to support the implementation of interfaces with non-virtual methods.

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

А по поводу вашего кода - не знаю насчёт C#, но С++ компилятор бы вообще тривиально оптимизировал бы и сделал эти функции - по крайней мере, func2(), а скорее всего и func1() - невиртуальными.

Вы сами себе противоречите. С одной стороны пишите, что они виртуальные, с другой соптимизирова и сделал невиртуальным. Это как вообщt?

[M. Ridcully]

Вы сами себе противоречите. С одной стороны пишите, что они виртуальные, с другой соптимизирова и сделал невиртуальным. Это как вообщt?

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

[OtherSide]

Вы сами себе противоречите. С одной стороны пишите, что они виртуальные, с другой соптимизирова и сделал невиртуальным. Это как вообщt?

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

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

[M. Ridcully]

OtherSide, я устал.
Постарайтесь перечитать то, что я написал выше. Мне добавить нечего.

[OtherSide]

OtherSide, я устал.
Постарайтесь перечитать то, что я написал выше. Мне добавить нечего.

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