Взять за основу такие базовые линуксовые вещи, как контрольные группы, пространства
имён, изоляцию процессов и т.д. и объединить их в одном инструменте — это потрясающее > достижение.
Вот это в постах о docker раздражает: "Пришел docker и появились контейнеры".
lxc был до docker и все те технологии перечисленные в цитате lxc соединил за 5 лет до docker. Да у lxc не такой удачный интерфейс (имеется ввиду CLI). Но это не значит что именно команда docker придумала контейнеры.
Жаль, что при таком подходе чуда все-таки не произошло.
Как было много подкрашено красным в полностью валидном проекте (CI его собирает на нескольких платформах несколькими разными компиляторами)
в самой первой доступной версии clion (2-3 года назад?), так и сейчас не понимает очевидные вещи типа:
«А вдруг вы и в рабочее время будете думать/работать над своим собственным/левым проектом»
Но в эту же логическую цепочку укладывается "нельзя заводить детей" — "а вдруг вы на работе будет думать о них", "нельзя делать ремонт квартиры",
да практически любая проблема решение которой занимает больше нескольких минут.
В качестве nextget плюсов по-моему пока только Rust выступает. Все-таки у обоих D и Go есть GC. Поэтому если вам не нужна zero cost abstraction, то стоит задуматься может подойдут не компилируемые в native языки, типа Java, C# и т.д.
По крайней мере с правами доступа проблема. Насколько я понимаю для связки типа git+ssh нельзя назначить доступ людям на основе веток. В github вроде нет таких проблем. Но с ним другая проблема, если всю работу сосредоточить в одном репозитории с ветками для мантейнеров есть большая вероятность утонуть под количеством issue и pull request, даже при наличии меток и прочего.
И какие такие "превентивные инструменты" есть в других языках
По сравнению с ассемблером в языках типа C/Rust/D есть типизация,
которая на этапе компиляции позволяет предотвратить запись скажем целого числа на место числа с плавающей запятой. Я думаю имелось это ввиду.
а что поделать, тут пользуются аппаратным ускорением логарифмирования
можно написать так:
float FastInvSqrt(float x) {
float xhalf = 0.5f * x;
int32_t i;
memcpy(&i, &x, sizeof(i)); // представим биты float в виде целого числа
i = 0x5f3759df - (i >> 1); // какого черта здесь происходит ?
memcpy(&x, &i, sizeof(x));
x = x*(1.5f-(xhalf*x*x));
return x;
}
современный компилятор заинлайнит memcpy с фиксированным размером,
и в результате будет тот же код, что и задумывался,
зато ни UB, ни прочих непрятных эффектов
В Яндекс.Картах 4 исполняемых файла — основное приложение и три виджета. Если статически влинковать в них рантайм, то размер приложения вырастет на 60-70 мб
А откуда такие цифры, проверяли? При статической линковке в отличие от динамической можно удалить ненужный код (флаг -dead_strip и его аналоги) и вполне возможно что за счет этого суммарный размер уменьшится, а не увеличится, т.к. каждый бинарник возьмет из runtime только малую часть и сумма будет меньше размер всего runtime в виде .so.
Нет гарантий, что стор примет такую сборку. В архиве, отправляемом в стор, лежит папка SwiftSupport, содержащая неподписанные библиотеки swift runtime, т.е. к ним особое отношение
А откуда будут какие-то папки, у вас же будет статическая линковка, кроме как дизасемблированием понять писали ли вы на swift или objective-c не должно быть возможным?
В итоге остаются только библиотеки swift runtime и vendored-фреймворки
Возможно глупый вопрос, но я под iOS никогда не разрабатывал,
а почему нельзя swift runtime пересобрать из исходников в статическую библиотеку?
Вроде бы исходники доступны?
Вот это в постах о docker раздражает: "Пришел docker и появились контейнеры".
lxcбыл до docker и все те технологии перечисленные в цитатеlxcсоединил за 5 лет до docker. Да уlxcне такой удачный интерфейс (имеется ввиду CLI). Но это не значит что именно командаdockerпридумала контейнеры.Жаль, что при таком подходе чуда все-таки не произошло.
Как было много подкрашено красным в полностью валидном проекте (CI его собирает на нескольких платформах несколькими разными компиляторами)
в самой первой доступной версии clion (2-3 года назад?), так и сейчас не понимает очевидные вещи типа:
говорит что
pair::operator=deleted, хотя очевидно что это не так.Но Москва не сразу строилась, может быть через лет 5 уже вашу IDE будут
использовать для проверки правильности работы компилятора.
Насколько я слышал вы пишете не просто свой парсер, а два своих C++ парсера?
Один в CLion другой в resharper. Или вы все-таки решили один делать?
Я в свое время написал инструмент именно для тестирования GUI написанного на Qt:
https://habrahabr.ru/post/301702/
там в комментариях приводят и аналоги.
А сравнение с индексом широты/долготы который postgis использует?
Но в эту же логическую цепочку укладывается "нельзя заводить детей" — "а вдруг вы на работе будет думать о них", "нельзя делать ремонт квартиры",
да практически любая проблема решение которой занимает больше нескольких минут.
Серьезно, "новая файловая система" и этого мало?
В качестве nextget плюсов по-моему пока только Rust выступает. Все-таки у обоих D и Go есть GC. Поэтому если вам не нужна zero cost abstraction, то стоит задуматься может подойдут не компилируемые в native языки, типа Java, C# и т.д.
В maps.me ядро на c++, а интерфейс для android на java.
По крайней мере с правами доступа проблема. Насколько я понимаю для связки типа git+ssh нельзя назначить доступ людям на основе веток. В github вроде нет таких проблем. Но с ним другая проблема, если всю работу сосредоточить в одном репозитории с ветками для мантейнеров есть большая вероятность утонуть под количеством issue и pull request, даже при наличии меток и прочего.
По email. Просто вставляешь патч в письмо и отправляешь с CC в список рассылки.
По сравнению с ассемблером в языках типа C/Rust/D есть типизация,
которая на этапе компиляции позволяет предотвратить запись скажем целого числа на место числа с плавающей запятой. Я думаю имелось это ввиду.
А какой-нибудь из указанных проектов имеет UI тесты, т.е. использует robotium/expresso или их аналог?
Есть например eCos ядро на C++, а API для пользователя на C или C++.
Opensource не очень популярна, но вроде коммерческая еще держится.
Если говорить о объектах и шаблонах и ОСРВ сразу вспоминается eCos. Немногие ОСРВ были написаны в то время на
C++.можно написать так:
современный компилятор заинлайнит memcpy с фиксированным размером,
и в результате будет тот же код, что и задумывался,
зато ни UB, ни прочих непрятных эффектов
А отправить but report Microsoft не думали?
А откуда такие цифры, проверяли? При статической линковке в отличие от динамической можно удалить ненужный код (флаг
-dead_stripи его аналоги) и вполне возможно что за счет этого суммарный размер уменьшится, а не увеличится, т.к. каждый бинарник возьмет из runtime только малую часть и сумма будет меньше размер всего runtime в виде.so.А откуда будут какие-то папки, у вас же будет статическая линковка, кроме как дизасемблированием понять писали ли вы на swift или objective-c не должно быть возможным?
Возможно глупый вопрос, но я под iOS никогда не разрабатывал,
а почему нельзя swift runtime пересобрать из исходников в статическую библиотеку?
Вроде бы исходники доступны?
Было бы интересно про опыт использования
tokioв более подробном изложении.