В чем разница между двумя этими определениями инициализированных локальных переменных С/С++?

char buffer[32] = { 0 };
char buffer[32] = {};

Одно отличие состоит в том, что первое допустимо в языках С и С++, а второе — только в С++.

Что ж, давайте тогда сосредоточимся на С++. Что означают эти два определения?

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

Эти определения несколько различаются, но по факту результат один — весь массив должен быть инициализирован нулями. Поэтому согласно правилу «as-if» в С++ они одинаковы. То есть любой достаточно современный оптимизатор должен генерировать идентичный код для каждого из этих фрагментов. Верно?

В начале весны ABBYY LS совместно с Xerox запустили сервис для перевода документов Xerox Easy Translator Service. Изюминкой этого сервиса является приложение, запускаемое на МФУ Xerox и позволяющее отсканировать необходимое количество документов, дождаться перевода на один из выбранных 38 языков, произвести печать перевода — и все это не отходя от МФУ.

Приложение запускается на определенной серии МФУ Xerox на основе технологии Xerox ConnectKey с сенсорным экраном 800x480 точек. Аппаратная начинка МФУ зависит от конкретной модели, например, наша тестовая малютка Xerox WorkCentre 3655 имеет на борту 1Ghz Dual Core процессор и 2Gb оперативной памяти. Как ни удивительно, но МФУ имеет встроенный webkit-браузер, а наше приложение — это обычное html-приложение, разработанное на AngularJS 1.3.15.

О самом проекте мы писали в блоге раньше, а эта статья посвящена одному из увлекательных этапов проекта, а именно оптимизации AngularJS под работу на МФУ Xerox. Как оказалось на деле, платформа МФУ практически не накладывает никаких серьезных ограничений на разработку приложений, и они работают практически так же, как и на десктопных webkit-браузерах, за исключением одного НО —

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

Что такое LLVM?

LLVM — это по-настоящему удобный для разборки и сборки «ранний» компилятор для таких традиционных языков программирования, как C и C++.

LLVM настолько хорош, что считается «больше, чем просто компилятором» (это динамический компилятор, он работает с языками, не относящимися к семейству C, он представляет собой новый формат доставки для App Store и т. д. и т. п.). Все перечисленное верно, но для нашей статьи важно лишь приведенное выше определение.

LLVM имеет несколько ключевых отличий от других компиляторов:

• Главное новшество — промежуточное представление (ПП). LLVM работает с ПП, которое действительно можно прочитать (если вы умеете читать ассемблерный код). Возможно, кому-то это не покажется столь уж большим откровением, однако это свойство очень важно. ПП других компиляторов обычно имеют настолько сложную структуру, что их невозможно записать вручную, трудно понять и использовать.

Эрик Рэймонд (Eric Raymond) в своем эссе «Собор и базар» сказал знаменитую фразу:

«При достаточном количестве глаз все ошибки выплывают на поверхность».

Имеется в виду, что программное обеспечение с открытым исходным кодом по определению содержит меньше ошибок, чем ПО с закрытым исходным кодом, потому что код доступен для изучения всем и каждому. Рэймонд назвал это наблюдение «законом Линуса».

В некотором смысле, конечно, так и есть. Если исходный код могут увидеть всего 10 штатных программистов вашей компании, вряд ли результаты будут такими же, как если бы этот код лежал на всеобщем обозрении, скажем, на GitHub.

Однако переломным моментом для закона Линуса стало обнаружение уязвимости Heartbleed в OpenSSL — катастрофического эксплойта в результате серьезной ошибки в ПО с открытым исходным кодом. Каковы были масштабы катастрофы? Уязвимыми оказались примерно 18% всех сайтов с включённым HTTPS в мире. В результате злоумышленники могли просматривать весь трафик этих сайтах в незашифрованном виде… в течение двух лет.

Вы считали эти сайты защищёнными? Как же. Эту ошибку не замечали два года.

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

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

Немного о терминах
Строго говоря, сайты не переводят, а локализуют. Локализация — это не просто перевод с одного языка на другой. Это комплексная адаптация к культуре и реалиям рынка, в результате которой тексты на сайте, графика, мультимедиа, верстка — все выглядит так, как этого ожидает целевая аудитория. Именно поэтому очень важно учесть множество нюансов, в том числе таких, которые на первый взгляд могут показаться незначительными. К примеру, подумать о длине слов в целевом языке (в английском они короче, чем в русском, а в немецком — длиннее) уже на этапе проектирования интерфейса. Например, «выход» и «exit» ещё не так сильно отличаются, а вот немецкий «Beenden» и китайский 退出 уже тянут на задачку для дизайнеров интерфейса.

«Пожалуйста, напишите на C++ функцию, которая получает диаметр круга как float и возвращает длину окружности как float».

Звучит как задание на первой неделе курса по C++. Но это только на первый взгляд. Сложности возникают уже на первых этапах решения задачи. Предлагаю рассмотреть несколько подходов.

Студент: Как вам такой вариант?

#include <math.h>
float CalcCircumference1(float d)
{
    return d * M_PI;
}

Преподаватель: Да, этот код может нормально откомпилироваться. А может и нет.

Обсуждение начну с весьма печального твита Криса Аллена (Chris Allen, @bitemyapp):

«Мне немного грустно от того, что некоторые организации твердят мантру „Вы сможете использовать haskell“, чтобы заполучить толковых инженеров подешевке».

— Untyped is unsane ( @bitemyapp) 3 июня 2014 г.

Для тех, кто не знает: Haskell — продуктивный и мощный язык, позволяющий программистам, по крайней мере талантливым, быстро писать правильный код. По сравнению с разработкой на Java скорость возрастает в 2–5 раз при сопоставимой производительности и меньшем количестве ошибок. Крис совершенно верно заметил, что разработчик, использующий Haskell, чаще всего не получает достойного вознаграждения. Если вы твердо решили использовать функциональное программирование, то будете зарабатывать меньше коллег, которые разгребают базы кода C++ в банках, накопленные за 30 лет. Как-то это все неправильно. Почему к программистам, применяющим более мощные инструменты, применяются экономические санкции? В отличие от управленцев, ставящих во главу угла выгоду, программисты действительно хотят сделать свою работу как можно лучше. Почему же вместо «пряника» за благие намерения они получают «кнут»?

Кажется, мы только объявили об официальном запуске проекта «Переведём Coursera», а наши добровольцы уже преодолели рубеж в первый миллион переведенных слов. Благодарим всех участников — вы настоящие молодцы. Для вас мы подготовили специальную страницу, где собрали поздравления и инфографику в честь такого события.

Как вы знаете, в основе проекта лежит SmartCAT — собственная облачная платформа ABBYY Language Services для автоматизации перевода. Она позволяет всем переводчикам Coursera работать с современными технологиями для перевода в удобном интерфейсе: участники могут использовать Translation Memory, автоматизированную поддержку целостности терминологии, машинный перевод, просматривать видеофрагменты лекций. Мы постоянно обновляем этот технологический фундамент, чтобы ресурс стал удобнее и лучше помогал нашим участникам с переводом лекций.

Думаем мы не только об удобстве, но и о том, как волонтеров заинтересовать. Недавно на проекте заработала система наград — ачивки. Они отражают успехи участников в переводе Coursera. Наши разработчики поделились, как устроена эта система и как она работает. Вот об этом мы вам сегодня и расскажем.

В конце мая в Москве мы (ABBYY Language Services) собирали представителей индустрии перевода и локализации на круглый стол TAUS, чтобы всем вместе поговорить об автоматизации перевода: что это такое, какая от этого польза, что с этим делать и кому это нужно. Разговор получился продуктивным, чем мы очень довольны. Теперь мы расскажем вам об одном из докладов, который стал лучшим по итогам круглого стола и позволил его автору получить специальную награду TAUS Excellence Award.



Доклад, на котором мы остановимся, был посвящен теме машинного перевода (MT). Вообще, о машинном переводе говорили многие участники. Например, что его популярность не снижается, и многие обычные пользователи и компании начали активнее использовать его в своей работе – только через Яндекс.Перевод ежедневно проходит около 100 Гб информации.

24 марта ABBYY Language Services и центр Digital October объявили об официальном запуске краудсорсингового проекта «Переведем Coursera». Его цель — на волонтерской основе перевести лучшие курсы Coursera на русский язык и сделать их доступными для всех пользователей Рунета. Зарегистрироваться и приступить к переводу лекций можно уже сейчас на сайте проекта.

Пока мы разрабатывали и готовили к запуску этот проект, произошло много интересного. Мы решили массу организационных и технических задач, познакомились с большим количеством интересных людей, в том числе с яркой командой и основателями Coursera, а также с командой нашего локального партнера по этому проекту Digital October. Думаем, что вам будет интереснее узнать про технологии, поэтому сейчас расскажем, из чего состоит и что умеет платформа, которую мы разработали. Почти наверняка это не последний пост о проекте, так что пишите в комментариях, о чем еще вы бы хотели узнать.

Работа переводчиков интересна: через них постоянно проходит много информации на разных языках. Часто случается, что перевод очередной 100-страничной инструкции нужен был ещё вчера. И если похожие тексты уже переводились ранее (предыдущие версии инструкции или другая техническая документация), то задача может быть немного проще, но при этом заниматься копипастом и следить, чтобы все изменения были учтены, то еще занятие. Для того чтобы использовать уже существующий перевод и обеспечить при этом его последовательность существует специальный класс программ, называемых CAT-инструментами.

CAT расшифровывается как Computer-Aided (Assisted) Translation – «перевод с помощью компьютера» или «автоматизированный перевод». Но не стоит отождествлять данные технологии с машинным переводом, когда вы вводите текст на одном языке, нажимаете кнопку и получаете его перевод: автоматизированный перевод — более широкое понятие, и в случае CAT-систем используется уже имеющийся перевод, сделанный человеком.

На днях ABBYY Language Services начала закрытое тестирование SmartCAT — собственной платформы для автоматизации процесса перевода. И в этом посте мы постараемся немного рассказать, что умеют делать CAT-системы.

Многие переводчики при работе над специализированными текстами сталкиваются с тем, что иногда до 90% времени уходит на поиск нужных терминов. При этом в каждой компании, которая так или иначе связана с зарубежными партнерами, есть свои материалы на разных языках. Как правило, переводчики, которые их создают, ведут глоссарии, где все правильные термины перечислены, проблема обычно заключается в том, чтобы ими делиться и переиспользовать. На западном рынке давно разработаны технологические решения, которые упрощают этот процесс. Недавно мы (ABBYY Language Services) объявили о выходе бета-версии ABBYY Lingvo.Pro — собственного облачного решения по управлению корпоративной терминологией.

Из этой статьи вы узнаете:
— что такое корпоративная терминология и почему ради неё делают специальные программные продукты;
— зачем нам понадобилось делать своё решение, если есть похожие готовые;
— что умеет ABBYY Lingvo.Pro;

Знаки препинания — неотъемлемая часть любого языка. Обычная запятая может кардинально изменить значение предложения: достаточно вспомнить историю с «Казнить нельзя помиловать». А работа переводчиков и редакторов предполагает, что они свободно ориентируются как минимум в двух пунктуационных системах.

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

Недавно мы с коллегами побывали на конференции для тех, кто занимается локализацией всего на свете, — Localization World. Специализированных мероприятий для переводчиков не так уж и много. Есть мероприятия для фрилансеров, есть научные — к примеру, ежегодные конференции TAUS, есть отраслевые — как LegalTech. Localization World — единственное мероприятие, объединяющее тех, кто делает переводы, кто их заказывает и кто разрабатывает технологии для этой сферы. На ней обсуждают технологии, инструменты, системы статистики, сервисы и многое другое, без чего переводчику жить можно, но сложно.

Localization World стартовал в начале 2000-х годов — первая встреча состоялась осенью 2003 года в Сиэтле, и с тех пор проходит с аншлагом. Сначала конференция не была ежегодной, теперь же специалисты собираются аж на двух-трех LocWorld в год, в 2013 году уже прошли встречи в Сингапуре и Лондоне, последняя — 12-14 июня, а в начале октября мероприятие пройдет в США, в Силиконовой долине. На мероприятия приезжают около 400-500 человек, а это достаточно много для отрасли.