Это является всегда злым, чтобы иметь структуру с методами?

Когда я контролирую руководства по стилям, все определяется как struct . Исторически я хотел, чтобы все мои объекты были тем или иным, так как меня учили, что это поведение undefined для пересылки объявленной структуры как класса, и наоборот (я не уверен, было ли это когда-либо на самом деле правдой, просто Мне сказали). И действительно, struct имеет более разумное состояние по умолчанию.

Я до сих пор делаю то же самое, потому что никогда не был убежден в ценности использования этого документа как формы документации. Если вам нужно передать, что у объекта есть только открытые члены, или нет никаких функций-членов, или любая произвольная линия, которую вы выбрали для рисования между ними, у вас есть фактическая документация для этого. Поскольку вы на самом деле никогда не используете ключевое слово struct или class при использовании типа, вам все равно придется искать определение, если вам нужна информация. А поскольку у каждого есть собственное мнение о том, что на самом деле означает struct , его полезность в качестве самодокументирования снижается. Поэтому я стремлюсь к последовательности: все как одно, так и другое. В данном случае struct .

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

Я часто использую struct.

Для "традиционных" классов ООП (тех, которые представляют конкретную "вещь") я склонен использовать class просто потому, что это общепринятая конвенция.

Но большинство моих классов на самом деле не являются объектами ООП. Они обычно являются функторами, классами-трейтами и другими более абстрактными концепциями кода, которые я использую для самовыражения, а не для моделирования конкретных "вещей". И их я обычно делаю struct. Это избавляет меня от необходимости вводить начальные public:, а значит, делает определение класса короче и проще для восприятия.

Я также склоняюсь к тому, чтобы делать большие, более сложные классы class. Только это редко на что-то влияет, потому что я еще больше склоняюсь к рефакторингу больших, сложных классов... И тогда у меня остаются маленькие простые, которые можно сделать struct'ами.

Но в любом случае, я бы не считал это "злом". "Зло" - это когда вы делаете что-то, что активно запутывает ваш код, или когда вы делаете что-то намного сложнее, чем нужно.

Но каждый программист C++ знает, что struct и class означают практически одно и то же. Вы не будете долго путаться, увидев struct Animal {...}; Вы знаете, что это класс, предназначенный для моделирования животного. Так что нет, это не "зло", независимо от того, каким способом вы это делаете.

Что касается языка, это не имеет значения, за исключением стандартного private против public доступа. Выбор субъективен.

Я бы лично сказал использовать struct для POD, но помните, что "POD" не означает "никаких функций-членов". Это означает отсутствие виртуальных функций, конструкторов, деструкторов или operator=.

Edit: Я также использую structы для простых публичных-доступных агрегатов данных, даже если их члены не являются POD.

Вы сказали: "Для меня struct интуитивно является коллекцией полей - узлом структуры данных или чем-то еще". То, что вы описываете - это Plain Old Data. В стандарте C++ действительно есть мнение о том, что означает POD применительно к возможностям языка C++. Я предлагаю вам, по возможности, принять значение POD, используемое в C++0x.

Мне нужно найти ссылку на это, но я думал, что в C++0x ключевые слова "struct" и "class" должны быть синонимами в том, что касается определения типов. Единственное различие заключается в том, что класс по умолчанию имеет закрытые члены, а struct - открытые. Это означает, что вы никогда не увидите сообщений об ошибках компилятора типа "Type X first seen using struct, now seen using class.", когда мы все будем использовать C++0x.

Я думаю, что неправильно иметь строгие правила относительно того, когда использовать class, а когда struct. Если для вас важна последовательность, то идите вперед и создайте стандарт кодирования с любыми правилами, которые вам нравятся. Только убедитесь, что все знают, что ваш стандарт кодирования относится к тому, как вы хотите, чтобы выглядел ваш код - он не относится к базовым возможностям языка.

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

Я бы предположил, что если вы думаете, что ключевые слова struct и class имеют какое-то отношение к концепции POD, то вы еще не понимаете C++.

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

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