… а потом ещё настроит и эмулятор, потому что всё равно придётся бинарник копировать. Я считаю что если есть компьютер целевой платформы достаточной мощности для разработки, то лучше разрабатывать нативно.
К сожалению, да. Сегодня на настоящих HPC машинах минимальным является 1 Gb RAM на ядро, а чаще всего — 2 Gb. А про интерконнект вообще даже не стоит сравнивать — стоимость Infiniband доходит до половины стоимости всей системы и счёт идёт на микросекунды задержки.
Если фронтэнд начали писать 10+ лет назад, то так и есть.
Исходный код и процесс разработки MSVC закрыт, а вот в GCC пытаются добавить caret diagnostics, но это очень тяжело даётся. Особенно учитывая то, что «однопроходные компиляторы» и другие «прикольные трюки» были тогда в моде и в AST GCC сразу сворачивает константные выражения. То есть AST не соответствует исходному коду и вообще выдавать по нему диагностики — подвиг (не говоря уже о caret diagnostics).
> В си когда-то отдельным проходом обрабатывались дефайны
Сейчас препроцессор и парсер работают в одном проходе (по множеству причин, но вот одна из них, которая показывает что это действительно так — если бы препроцессор работал отдельно, в диагностиках вы получите ссылки не ваш исходный код, а на отпрепроцессеный).
> бывало, отдельным проходом переводился C++ в С
Покажите хотя бы один популярный, рабочий, соответствующий стандарту и портабельный C++ компилятор, построенный по такой схеме — и эмбеддедщики завалят вас деньгами.
> А ещё где-то я видел отдельный перевод С в текст на ассемблере.
А у паскаля что, прямо AST процессор исполнять будет?
Хватит уже про эту «однопроходность». Сегодня любой компилятор, любого языка, который хочет выдавать нормальные диагностики и делать оптимизации, является многопроходным. Просто проходы идут не по исходному коду, по по внутреннему представлению.
В реальном компиляторе Паскаля (или Делфи) максимум парсер однопроходный (как и в Си, между прочим). А любые оптимизации (машинно-зависимые и независимые) всё равно отдельные проходы.
/tmp/zzz.cc:6:28: warning: 'memset' call operates on objects of type 'S' while the size is based on a different type 'S *'
[-Wsizeof-pointer-memaccess]
memset(this, 0, sizeof(this));
~~~~ ^~~~
/tmp/zzz.cc:6:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(this, 0, sizeof(this));
^~~~
> Как обычно, мы можем увидеть здесь кучу разных вещей, но одна из них наиболее интересна для нас это записи с классом W (что означает «слабый» символ («weak» symbol)) а также записи именем секции типа ".gnu.linkonce.t.stuff". Это маркеры для конструкторов глобальных объектов
Конструктор Fred::Fred() помечен как weak потому что он неявно объявлен как inline, и компилятор будет генерировать для него код в кажой единице трансляции, где есть это определение, а значит линковщик должен убрать лишние копии этой функции.
Исходный код и процесс разработки MSVC закрыт, а вот в GCC пытаются добавить caret diagnostics, но это очень тяжело даётся. Особенно учитывая то, что «однопроходные компиляторы» и другие «прикольные трюки» были тогда в моде и в AST GCC сразу сворачивает константные выражения. То есть AST не соответствует исходному коду и вообще выдавать по нему диагностики — подвиг (не говоря уже о caret diagnostics).
Сейчас препроцессор и парсер работают в одном проходе (по множеству причин, но вот одна из них, которая показывает что это действительно так — если бы препроцессор работал отдельно, в диагностиках вы получите ссылки не ваш исходный код, а на отпрепроцессеный).
> бывало, отдельным проходом переводился C++ в С
Покажите хотя бы один популярный, рабочий, соответствующий стандарту и портабельный C++ компилятор, построенный по такой схеме — и эмбеддедщики завалят вас деньгами.
> А ещё где-то я видел отдельный перевод С в текст на ассемблере.
А у паскаля что, прямо AST процессор исполнять будет?
Хватит уже про эту «однопроходность». Сегодня любой компилятор, любого языка, который хочет выдавать нормальные диагностики и делать оптимизации, является многопроходным. Просто проходы идут не по исходному коду, по по внутреннему представлению.
Как-то слабо. Статья в двух словах: сначала следуйте мануалу по вашей реализации MPI, затем мануалу по CUDA.
Я ожидал рассказ про прямое копирование данных между памятью разных карт при помощи MPI и прочие классные штуки.
Конструктор Fred::Fred() помечен как weak потому что он неявно объявлен как inline, и компилятор будет генерировать для него код в кажой единице трансляции, где есть это определение, а значит линковщик должен убрать лишние копии этой функции.
It depends.
В Linux — да. В Darwin — нет, добавляется "_".