XML. За и против

Один из создателей стнадарта XML, Тим Брей, написал заметку XML Is Too Hard For Programmers, а затем еще одну, менее пессиместичную Why XML Doesn't Suck. Обе заслуживают внимания.

Кроме того, существует еще один, весьма интересный документ (требуется регистрация): The Pros and Cons of XML

Вроде все доводы за вполне разумны. Все красиво на бумаге - данные и метаданные хранятся вместе, interoperability, readability как для людей так и для машин, обобщенный стандарт для представления Unicode, хранить можно древовидные и плоские данные и прочая, прочая. А то что чересчур большие файлы - ничего страшного, можно юзать сжатие, например на транспортном уровне. Сложно парсить и выбирать данные? Ничего, есть библиотеки для любого языка программирования. Нет нормальных XML-редакторов? Не беда, появятся.

И все же, всякий раз работая с XML-файлами возникает какое-то интуитивное неприятие. "Блин, опять этот хренов XML!" - проносится мысль, когда появляется задача с исходными данными в этом формате. Кажется что-то очень, в корне не правильно.

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

А ведь XML ни в коем разе не является форматом хранения данных, хотя в последнее время частенько наблюдается тенденция к его использованию именно для этого. Изначально назначение XML - передача данных и interoperability. XML - является форматом write-once, то есть он не предназначен для того, чтобы записать на хард, а потом иногда вносить изменения. Его назначение в том, однажды вывести свои данные в формате XML, чтоб кто-то это прочел преобразовал в свой формат и всё! На этом жизнь XML-файла должна заканчиваться.

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

А сейчас есть тенденция подменять БД статическими XML-файлами, при том, что главное назначение СУБД: не хранение данных, а обеспечение параллельного доступа к ним из разных процессов, с атомарными операциями. Данніе можно сохранять любым способом - хоть на бумаге единички и нолики рисовать или в перфокартах дырки долбить. но параллельный доступ и атомарные операции - это совсем другая вещь, для которой и создаются СУБД.

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

Какой формат проще для чтения и редактирования (для человека)?

127.0.0.1     localhost locahost.mydomain.com
11.12.13.14   myhost    myhost.mydomain.com

или

<?xml version="1.0" encoding="ISO-8859-1"?>
<hosts>
 <host type="IPv4">
   <address>127.0.0.1</address>
   <aliases>
     <alias>localhost</alias>
     <alias>localhost.mydomain.com</alias>
   </aliases>
 </host>
 <host type="IPv4">
   <address>11.12.13.14</address>
   <aliases>
     <alias>myhost</alias>
     <alias>myhost.mydomain.com</alias>
   </aliases>
 </host>
</hosts>
 

Тест на знание C++

Вот интересный тест.

Your score is 86%. You got 43 answers correct out of a possible 50 questions.

Непорядок. Нужно будет подучить матчасть.

о Sequence points и undefined behaviour

На различных программистских форумах в темах типа "интересные задачки" с завидной регулярностью появляются сообщения типа

Чему будет равно i после

int i=5;
++i++;

или
чему будет равно b:

int a = 5, b;
b = ++a + ++a;

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

Правильный ответ в обоих случаях один и тот же - неизвестно. То есть компилятор что-то выдаст, но предугадать, что же случится - невозможно. Все дело в точках следования или Sequence points.

Как известно, точки следования представляют собой такие ситуации, когда состояние исполняемого кода соответствует состоянию абстрактной машины, которая описана стандартом языка C++.

Обратимся к этому замечателному документу:

Standard for Programming Language C++, Chapter 1

At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

Стандарт требует, что бы в кадой точке следования все побочные эффекты кода, который уже выполнен, уже произошли, а побочные эффекты для кода, который еще не был выполнен еще не произошли.

Точки следования возникают в следующих ситуациях:

Standard for Programming Language C++, Chapter 1

15 There is a sequence point at the completion of evaluation of each full-expression.
16 When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all
function arguments (if any) which takes place before execution of any expressions or statements in the function body. There is also a sequence point after the copying of a returned value and before the execution of any expressions outside
the function13). Several contexts in C++ cause evaluation of a function call, even though no corresponding function call
syntax appears in the translation unit. [ Example: evaluation of a new expression invokes one or more allocation and
constructor functions; see 5.3.4. For another example, invocation of a conversion function (12.3.2) can arise in contexts
in which no function call syntax appears. -end example ] The sequence points at function-entry and function-exit
(as described above) are features of the function calls as evaluated, whatever the syntax of the expression that calls the
function might be.
17 In the evaluation of each of the expressions
a && b
a || b
a ? b : c
a , b
using the built-in meaning of the operators in these expressions (5.14, 5.15, 5.16, 5.18), there is a sequence point after
the evaluation of the first expression14).

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

Вот что говорит Стандарт о вычислениях между точками следования:

Standard for Programming Language C++, Chapter 5

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions,
and the order in which side effects take place, is unspecified. Between the previous and next sequence point a
scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior
value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for
each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

[ Example:
i = v[i ++]; / / the behavior is undefined
i = 7 , i++ , i ++; / / i becomes 9
i = ++ i + 1; / / the behavior is undefined
i = i + 1; / / the value of i is incremented
-end example ]

Т.е. любое выражение, изменяющее скалярный объект несколько раз или считывающее его значение после изменения в промежутке времени от одной точки следования к другой при вычислениях приводит к неопределенному поведению или undefined behavior.

Таким образом, к примеру, вот здесь

b = ++a + ++а;

мы имеем дело как раз с этим самым undefined behavior. Т.е. согласно Стандарту С++ поведение неопределено, а значит в результате выполнения b может быть равным как 14 так и 13 так и стать равным абсолютно произвольному значению.