Как Greg сказал, можно использовать структуру, если Вы имеете дело с двоичными значениями, но если у Вас просто есть "шестнадцатеричное число", но в формате байта Вы могли бы хотеть просто преобразовать ее как:
s = 'y\xcc\xa6\xbb'
num = int(s.encode('hex'), 16)
... это совпадает с:
num = struct.unpack(">L", s)[0]
... кроме он будет работать на любое число байтов.
мой личный порядок задается порядком внутри объявления класса:
class MyClass
{
public:
MyClass();
~MyClass();
void start();
protected:
static void init(MyClass *);
private:
int m_iCounter; ///< counter variable for....
};
будет выглядеть так в .cpp:
MyClass::MyClass() :
m_iCounter(0)
{
...
}
MyClass::~MyClass() {
...
}
void MyClass::start() {
...
}
void MyClass::init(MyClass *) {
...
}
Порядок определяется следующим образом:
сигналы
start ()
и stop ()
, затем геттеры и сеттеры Надеюсь, что это поможет.
ciao, Крис
Это может показаться глупым, но я пытаюсь упорядочить свои общедоступные методы по «порядок« нормального »использования», поэтому сначала идут конструкторы, затем общедоступные методы doStuff, затем методы закрытия ... исключение из этого «правила» - деструктор ~, который идет после последнего конструктора.
Последним идет любой частные "вспомогательные" методы.
Я использую этот же подход на всех языках ... (C ++, Java, C #, Perl, sh или что-то еще), и на самом деле никто не застрелил меня за это (пока).
Ура. Кейт.
Я привык к порядку с платформы Symbian, где порядок следующий:
Причина в том, что руководствовались правилами расширения уже выпущенных интерфейсов для обратной совместимости. Поскольку наиболее вероятно добавить частную переменную, они помещаются в конец класса, чтобы добавление новой не изменило расположение любых других переменных в классе. Вещи, которые изменяют интерфейс, затем идут перед этим в порядке «общедоступный, защищенный». Затем порядок копируется для методов класса, хотя они не изменяют расположение в памяти каких-либо переменных в экземпляре класса.
И не спрашивайте о правилах для виртуальных функций;)
Сейчас это гораздо менее важно, чем раньше. Все достойные IDE в наши дни имеют (или должны иметь) возможность переходить к определению или ссылке с помощью щелчка правой кнопкой мыши или другого простого жеста. Перебирать код - пустая трата времени.
Обычно я их заказываю: Конструктор Деструктор В каком бы порядке я не реализовал остальное
, я затем возвращаюсь и группирую логические / связанные функции вместе
Вероятно, более важно сгруппировать связанные вещи / упорядочить вещи в файле заголовка для удобства чтения, чем в файле cpp.
Внутри класса не существует строгих правил языка. Вне класса вам необходимо убедиться, что объявление предшествует определению, когда они разделены.
В общем, вы обнаружите, что команда, с которой вы работаете, устанавливает любые правила форматирования исходных файлов. Однако это просто эстетика, поскольку она не влияет на фактическое выполнение программы.
Стандарт нашей компании:
От самого важного к самому низкому:
Сами методы должны быть упорядочены по их «уровню абстракции»: более высокий уровень: вверх, более низкий уровень: вниз, другими словами, структурируйте ваш методы, чтобы они вызывали только методы, указанные ниже.
Иногда бывает удобно иметь несколько локальных вспомогательных функций в безымянном пространстве имен (также известном как анонимное пространство имен ) в файле CPP. Если это так, я бы рекомендовал разместить эти функции сверху (в файле CPP), просто чтобы быть уверенным, что они определены до любой другой функции, которая их вызовет.
] Я использую свою среду IDE для перехода к функциям в моем файле cpp, и она упорядочивает их в алфавитном порядке, или я выполняю поиск, и с поиском во время ввода, это очень быстро.
Так что для меня нет абсолютно никакой разницы в рабочий процесс в зависимости от порядка функций в файле .cpp ...