Аналогичным образом определяются функции, сохраняющие в буфер данные и извлекающие из буфера информацию:

typedef unsigned char byte t; template<class T>

inline size t save(const T& i, byte t* buf)

*((T*)buf) = i;

return get size(i);

template<class T>

inline size t restore(T& i, const byte t* buf)

i = *((T*)buf);

return get size(i);

Понятно, что это работает только для простых типов (int или float), уж очень много чего наворочено: явное приведение указателя к другому типу, оператор присваивания... конечно же, очень нехорошо, что такой save() доступен для всех объектов. Понятно, что очень просто от него избавиться, убрав шаблонность функции и реализовав аналогичный save() для каждого из простгх типов данных. Тем не менее, это всего-лишь примеры использования:

template<>

inline size t save<MyObject>(const MyObject& s, byte t* buf)

...

Можно сделать и по другому. Например, ввести методы save() и restore() в каждый из сохраняемых классов, но это не столь важно для принципа этой схемы. Поверьте, это достаточно просто использовать, надо только попробовать. Мало того, здесь можно вставить в save<long>() вызов htonl() и в restore<long>() вызов ntohl(), после чего сразу же упрощается перенос двоичных файлов на платформы с другим порядком байтов в слове... в общем, преимуществ - море. Перечислять все из них не стоит, но как после этого лучше выглядит исходный текст, а как приятно вносить изменения

Оператор безусловного перехода goto

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

Но сначала о грустном. Обычно в вину goto ставится то, что его присутствие в языке программирования позволяет делать примерно такие вещи:

int i, j;

for(i = 0; i < 10;

if(condition1)

j = 4; goto label1;

...

for(j = 0; j < 10; j++) {

...

label1:

...

if(condition2)

i = 6;

goto label2;

...

label2:

...

Прямо скажем, что такое использование goto несколько раздражает, потому что понять при этом, как работает программа при ее чтении будет очень сложно. А для человека, который не является ее автором, так и вообще невозможно. Понятно, что вполне вероятны случаи, когда такого подхода требует какая-нибудь очень серьезная оптимизация работы программы, но делать что-то подобное программист в здравом уме не должен. На самом деле, раз уж мы привели подобный пример, в нем есть еще один замечательный нюанс - изменение значения переменной цикла внутри цикла. Смеем вас заверить, что такое поведение вполне допустимо внутри do или while; но когда используется for - такого надо избегать, потому что отличительная черта for как раз и есть жестко определенное местоположение инициализации, проверки условия и инкремента (т.е., изменения переменной цикла). Поэтому читатель исходного текста, увидев полный for (т.е. такой, в котором заполнены все эти три места) может и не заметить изменения переменной где-то внутри цикла. Хотя дя циклов с небольшим телом это, наверное, все-таки допустимо - такая практика обтчно применяется при обработке строк (когда надо, например, считать какой-то символ, который идет за спецсимволом , как \\ в строках на Си; вместо того, чтобы вводить дополнительный флаг, значительно проще, увидев \ , сразу же сдвинуться на одну позицию и посмотреть, что находится там). В общем, всегда надо руководствоваться здравым смыслом и читабельностью программы.

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

Тем не менее, вернемся к goto. Несмотря на то, что такое расположение операторов безусловного перехода несколько нелогично (все-таки, вход внутрь тела цикла это, конечно же, неправильно) - это встречается.

Итак, противники использования goto в конечном итоге приходят к подобным примерам и говорят о том, что раз такое его