Блог

 #define interface class
  

(вот еще — http://www.codeproject.com/KB/cpp/CppInterfaces.aspx )

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

Используете ли вы его? или «макросы — это зло»?

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

Похоже, что кто-то с опытом работы на C # / Java пытался найти свой путь в C и заблудился. Это привело бы только к ошибкам и путанице, с которыми столкнулись бы разработчики, действительно знакомые с C .

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

Лучший способ определения интерфейсов — использовать общее соглашение, такое как присвоение им имен с помощью «I» в качестве первого символа.

Я действительно не предлагаю использовать эти приемы, я считаю умником. Макросы не являются злом, но если кто-то включает ваш код и использует interface в качестве имени переменной (почему нет?), почему он / она должен тратить 1 час на отладку с gcc -E , потому что кто-то решил, что «интерфейс» (который не является C ) будет умнее?

Мне это не нравится.

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

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

Я бы также добавил, что идиомы особенно важны в C из-за возможности действительно сбить вас с ног, если вы не будете осторожны. На самом деле, наиболее часто используемые идиомы в C могут быть самой мощной функцией C .

Я бы никогда не стал переопределять или заменять существующее ключевое слово — это только приводит к путанице всех, кроме автора…

Это плохо. Я бы не стал его использовать, никогда.

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

Практически: это очень распространенное название «интерфейс», и его использование будет опасным именно на этом основании. Но, конечно, вы могли бы сделать имя более отчетливым, например, MY_PLATFORM_INTERFACE или что-то в этом роде.

С философской точки зрения: это явно неудачная попытка превратить C в более чистый язык ООП, такой как Java или C #, и попытка каким-то образом сделать синтаксис C более знакомым новичкам из мира Java / C #. Язык программирования — это то, что он есть. Если вы хотите внести глубокие изменения, обратитесь в комитет по стандартизации и будьте готовы предоставить убедительные доказательства. Я думаю, что такое небольшое изменение синтаксиса нелепо. Я не думаю, что кто-то не смог бы переключиться на C , потому что он не может привыкнуть к мысли, что ключевое слово interface не существует в C .

Идиоматически: Когда вы программируете на C , вы должны ожидать, что программисты C будут просматривать ваш код. Если вы введете подобную вещь, которая может выглядеть как непонятное расширение C , зависящее от компилятора, вы можете сбить с толку настоящего программиста C , и он может потратить свое драгоценное время, задаваясь вопросом, какой компилятор или расширение используется, чтобы включить это ключевое слово «interface». По возможности придерживайтесь идиоматического синтаксиса C . В противном случае вам придется комментировать рядом с каждым использованием «interface», что это ключевое слово является просто определением для «class», и в этом случае вы могли бы также просто прокомментировать объявление класса, что этот класс является интерфейсом, и просто использовать ключевое слово «class», как обычно.

Я не понимаю смысла этого делать. Как это помогает сделать код более читаемым для разработчиков? Или даже избегает делать его более неясным?

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

Вместо

 #define interface class
  

Рассмотрите возможность использования вместо этого ключевого слова Visual C __interface и напишите свой #define следующим образом:

 #ifndef _MSC_VER
#define __interface class
#endif
  

Также добавляйте в свои интерфейсные классы обычный префикс «I» для дополнительной ясности, как предложил @jonathan-wood.

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