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

[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х разных языковых конструкций для этого. Множественное наследование - это вообще третий механизм, к интерфейсам отношения не имеющий.