MikhailEdoshin

FileMaker (самое простое), Real Basic.

Может быть, просто тесты писать — написать развесистый пример со всеми возможными вариантами и тестовый код, чтобы посмотреть, как читается? Из инструментов на Питоне, например, есть такой construct, декларативный парсер для бинарных форматов, мне кажется, с ним тестировать должно быть удобно (хотя и с обычным struct можно легко написать специализированные тесты).

В целом же я присоединяюсь к предыдущему оратору — почему не использовать стандартный сериализатор?

Вы пишете, что функция у вас определена в заголовочном файле — вы имеете в виду, что весь код функции там или только объявление (то есть она объявлена, а не определена)? Мне кажется, только объявлена, иначе у вас, скорее всего, были бы дублирующиеся символы при линковке.

Вообще же extern inline функция (возможно) будет развернута в inline в той единице компиляции, где она определена, и из получившегося объекта будет торчать одноименный символ. Все остальные единицы компиляции будут использовать ее как обычную extern функцию. На SO есть небольшое обсуждение.

Если вы хотите развернуть ее во всех единицах компиляции, то можно, по примеру С++, описать функцию полностью в заголовочном файле как static inline плюс добавить не-static обертку для экспорта. (Или перед компиляцией слить все файлы в один — наверное, так будет даже проще.)

Новая функция SQLite? В смысле, новая функция, которой можно пользоваться в SQL-выражениях? Если так, то там ведь стандартный интерфейс добавления таких функций во время выполнения — зачем изменять саму SQLite?

Why so serious? :) Помнится, в конторе работал, так там каждую пятницу день программиста был (а у дизайнеров — соответственно, день дизайнера).

Pelles C? С++ нет. Windows. Скриншоты.

Посмотрите на FileMaker, может быть, подойдет. Это реляционная СУБД, у нее есть клиент/сервер для Мака и Windows, плюс клиенты под iPhone/iPad. Клиенты могут непосредственно работать с сервером или хранить базу локально; предполагается, что синхронизацию вы напишете тогда вручную. Из недостатков — эта СУБД изначально разрабатывалась для конечных пользователей, программисту с ней может быть сложно :) Скажем, SQL там считайте что нет. Ну и не бесплатная.

Нет. Как вы себе представляете работу такой функции? А если дом 122? Или 21? Тоже одинаковый хэш должен быть? А если улица «Масюковская» — тоже? А когда он должен делаться неодинаковый?

Есть фонетическое индексирование, которое выдает одинаковый хеш для слов, которые произносятся примерно одинаково — вполне возможно, что подобная функция для русского языка выдала бы одинаковый результат для «Васюковская» и «Васюковая», но не для всего адреса. Есть триграмный индекс для поиска похожих строк, но это не хэш.

Часто выбор формата делают либо через «расширение файла» (domain.com/method.xml vs method.json), либо через HTTP-заголовок Accept.

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

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

А то, к чему заголовки, под какой лицензией?

Advanced Mac OS X Programming, by Mark Dalrymple and Aaron Hillegass. Это главным образом Mac OS X со стороны Unix. Очень рекомендую. И у этого же Aaron Hillegass есть Cocoa Programming for Mac OS X, но ее я смотрел поверхностно, только одну главу, тоже оказавшуюся очень толковой. Еще по XCode мне понравилась книжка Step Into XCode, by Fritz Anderson, но та, что у меня, описывает довольно старую версию, не знаю, есть ли более новая.

Насчет подструктуры ничего сказать не могу, но это упрощенный алгоритм Кнута-Пласса о выключке абзаца, соответственно направление мысли — посмотреть их работу :) Из вики:

Formally, the algorithm defines a value called badness associated with each possible line break; the badness is increased if the spaces on the line must stretch or shrink too much to make the line the correct width. Penalties are added if a breakpoint is particularly undesirable: for example, if a word must be hyphenated, if two lines in a row are hyphenated, or if a very loose line is immediately followed by a very tight line. The algorithm will then find the breakpoints that will minimize the sum of squares of the badness (including penalties) of the resulting lines. If the paragraph contains n possible breakpoints, the number of situations that must be evaluated naively is 2n. However, by using the method of dynamic programming, the complexity of the algorithm can be brought down to O(n2) (see Big O notation). Further simplifications (for example, not testing extremely unlikely breakpoints such as a hyphenation in the first word of a paragraph) lead to an efficient algorithm whose running time is almost always of order n. A similar algorithm is used to determine the best way to break paragraphs across two pages, in order to avoid widows or orphans (lines that appear alone on a page while the rest of the paragraph is on the following or preceding page). However, in general, a thesis by Michael Plass shows how the page breaking problem can be NP-complete because of the added complication of placing figures.[18]