Например, в случае gettext все наблюдаемые (предназначенные для вывода) строковые литералы на английском обрамляются в вызов специального макроса _("...").
В сборку добавляется дополнительный этап генерации *.po-файлов, которые определяют маппинг исходных строковых литералов на локализованные сообщения. Полученный *.po-файл отдается переводчику.
Это, конечно, только часть локализации. Но существенно лучше, чем ничего.
При локализации
В большинстве языков есть готовые средства интернационализации, а то и локализации. В С/C++ часто используют gettext, C++/Qt — свой механизм, в Java i18n представлен ResourceBundle'ами. И т. д., и т. п.
Они позволяют довольно дешево подготовиться к интернационализации программы. С локализацией чуть сложнее, но тоже реально. Средства в библиотеках той же Java есть изначально.
Недоступны разработчику. Поясню, что имею ввиду. На многих контроллерах есть следующие инструкции сдвига вправо: логический, арифметический, циклический. Плюс эти же с участием бита в флаге переноса.
Из C с помощью операции >> доступен только один. В библиотеках компиляторов для таких архитектур, как правило, есть макросы, содержащие ассемблерные вставки для доступа.
И это нормально. Это — непереносимая часть, поэтому она не входит в состав С, разработанного, как низкоуровневый переносимый язык.
И то, и то может исполняться за 1 такт. Это уже не быстрее.
На суперскалярных архитектурах они вообще не сравнимы: что быстрее зависит от занятости модулей АЛУ и умножителей, зависимостей кода и других факторов. Дисциплин планирования исполнения микрокода, например.
То, что баг-репортер ожидал такого поведения не значит, что это баг.
В стандарте, процитированном выше, сказано, что если сдвиг вправо применен к отрицательному числу, то результат зависит от имплементации.
Стоит также помнить, что у разных процессоров разный набор инструкций. И довольно часто присутствуют и логический, и арифметический сдвиги вправо (старший бит расширяется вправо). Иногда ещё присутствуют до двух видов кольцевых сдвигов (в одном направлении). И в языке C используется только один вариант сдвига, остальные — недоступны.
Плюс есть большое количество разнообразных процессоров, микроконтроллеров и DSP, оптимизация в компиляторах которых хромает (и сдвиговые операции часто быстрее и удобнее, чем умножение/деление). И, естественно, для них нет высокоуровневых API, виртуальных машин.
MSP430 это general-purpose 16тибитный контролер с малым энергопотреблением, а никак не DSP. То, что в наборе инструкций присутствует MAC-операции его не делает DSP.
просмотр истории: git log
отправка сообщения: git commit --allow-empty --message «текст сообщения»
стереть последние N сообщения: git reset --hard HEAD~N
и т. п.
Многие программы используют не один файл для хранения состояния. Одна копия программы записала часть файлов, вторая — другую. Получили неконсистентное состояние. См. habrahabr.ru/post/141688/#comment_4738860
Классическая тема. Некоторые люди пытаются хранить репозитории в dropbox. Результат — битые репозитории на всех машинах.
Запись, сделанная в одно действие, неделимая. Преимущество в том, что иной процесс не видит переходных состояний (неполностью записанный файл, например).
По частотке (c наиболее встречаемыми на home row) расположен dvorak, а qwerty хоть и по частотке, но с совершенно другой идеей. На qwerty клавиши располагаются так, чтобы избежать зацепления головок на печатной машинке.
Например, в случае gettext все наблюдаемые (предназначенные для вывода) строковые литералы на английском обрамляются в вызов специального макроса _("...").
В сборку добавляется дополнительный этап генерации *.po-файлов, которые определяют маппинг исходных строковых литералов на локализованные сообщения. Полученный *.po-файл отдается переводчику.
Это, конечно, только часть локализации. Но существенно лучше, чем ничего.
При локализации
Они позволяют довольно дешево подготовиться к интернационализации программы. С локализацией чуть сложнее, но тоже реально. Средства в библиотеках той же Java есть изначально.
Из C с помощью операции >> доступен только один. В библиотеках компиляторов для таких архитектур, как правило, есть макросы, содержащие ассемблерные вставки для доступа.
И это нормально. Это — непереносимая часть, поэтому она не входит в состав С, разработанного, как низкоуровневый переносимый язык.
На суперскалярных архитектурах они вообще не сравнимы: что быстрее зависит от занятости модулей АЛУ и умножителей, зависимостей кода и других факторов. Дисциплин планирования исполнения микрокода, например.
В стандарте, процитированном выше, сказано, что если сдвиг вправо применен к отрицательному числу, то результат зависит от имплементации.
Стоит также помнить, что у разных процессоров разный набор инструкций. И довольно часто присутствуют и логический, и арифметический сдвиги вправо (старший бит расширяется вправо). Иногда ещё присутствуют до двух видов кольцевых сдвигов (в одном направлении). И в языке C используется только один вариант сдвига, остальные — недоступны.
отправка сообщения: git commit --allow-empty --message «текст сообщения»
стереть последние N сообщения: git reset --hard HEAD~N
и т. п.
Классическая тема. Некоторые люди пытаются хранить репозитории в dropbox. Результат — битые репозитории на всех машинах.
в общем, всё хорошо пока весь state в одном файле, запись которого атомарна.
См. en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard#Comparison_of_the_QWERTY_and_Dvorak_layouts
проверяйте расширения, там всякое бывает.