и иметь возможность прозрачно их переводить на другие языки
Вот с этого момента поподробнее. Возьмём, к примеру, бухгалтерию, где понятия “счёт” и “счёт-фактура” имеют между собой мало общего и, главное, первое понятие существует в англоязычных странах, а второе — отстстует и потому разные переводчики (человеческие, не машинные) его переводят по разному.
Как ваш прозрачно-переводчик решит эту проблему? Особенно когда особый термин — внутренний для предприятия?
Рискну предположить что мир автора заканчивается ровно на границе рф.
Хорошо, если так. Скорее всего он заканчивается на проходной, отделющий его отдел от соседних.
Собственно он и показывает как Роскосмосу удаётся достичь, даже без формального распила и откатов (они, возможно, и есть, но это, при такой организации, и неважно), одновременно двух достижений:
Фантастической стоимости всего, связанного с Роскосмосом.
Чудовищно низких зарплат у большинства работников.
А всё просто: если объявить, что у нас тут космос, всё супер-пупер уникальное, сделано под заказ и, условно говоря, вытачивать каждый болт на отдельном, созданом конкретно для этого болта станке и писать программы для каждого блока на отдельном, разработанном специально для этого блока, языке программирования… ооо… тут можно освоить любые средства́ и ещё мало будет.
Прям такой заповедник позднего СССР живой.
А ты высокомерно стремишься общаться (в широком понимании) на кириллице во имя не пойми чего.
Очень даже понятно по имя чего. Такой поход, когда, условно, цех левых тапочек понятия не имеет по какой технологии выпускаются правые тапочки не позволяет никого сократить. Ибо никто ни с кем не взаимозаменяем.
Ну почитайте же Паркинсона, он прекрасно всё описал.
Вы либо слишком молоды и начали играть при повальном распространении интернета с патчами и прохождениями, либо просто уже не помните.
Я прекрасно помню, что подавляющему большинству игроков ни номера Игромании, ни интернет были недоступны даже в начале XXI века.
А уж в прошлом веке это всё было доступно хорошо, если одному игроку из ста.
У нас в школе был Интернет, да, но когда кто-то попытался скачать несколько патчей для каких-то игр и выжрал квоту всей школы за месяц…
В общем игры для которых были нужны патчи были, скорее, редкими исключениями, чем правилом.
Редко какая RPG (привет, Troika Games!) не содержала в себе сотни ошибок, зачастую препятствующие дальнейшему прохождению.
Уж не знаю о каких годах вы говорите, но на PlayStation и PlayStation2 были десятки JRPG — и я не знаю ни одной, которую нельзя было бы пройти без каких-либо патчей. Troika Games выпускала игры для Windows, потому ситуация “если игра будет непроходима, то придётся отозвать весь тираж и, скорее всего, обанкртиться” им была незнакома.
Вы почитайте патч-ноуты на fallout 1&2, Проклятые Земли, Корсаров, Демиургов, Revenant и пр.
Это всё PC игры. Они начали портится быстрее чем консольные. По двум причинам: с начала века начало сильно диверсифицироваться железо, но, главное, появилась возможно выпускать сырые недоделки и потом — бесконечные патчи для них.
Игры были на порядки проще.
Не были. В том-то и дело, что не были. Графика была не на порядак, а на два проще — это да. А вот геймплей у многих PlayStation2 игр вполне себе не уступал современным, кое в чём даже превосходил.
Да, PlayStation2 — это вершина “неотзывных” игр, Xbox даже первый, как тут выше подсказали, кое-где уже начал скатываться в выпуск поделок, которые можно играть только через год после “оффициального релиза”, но это как раз и показывает, что причина всей этой бажности не в какой-то особой сложности современных игр, а банально в том, что выпуск бажных игр не приводит к диким убыткам.
А это было в эру до того, как консоли начали массово подключать к Интернет.
До Xbox (оригинального), PlayStation2 и Wii.
И вы знаете что? Писали. И игры работали. Да, ошибки были и тогда, но критичные до релиза не доживали и мешать не играли.
Да, разработака занимала дольше, но и сейчас многие игры разрабатываются по 3-4 года. Что мешает ещё полгода потратить на то, чтобы найти все критические баги и исправить?
Учитывая то, что вы понятия не имеете о чём говорите, думаю обсуждать бессмысленно, но…
Громкий заголовок, но учитывая что доля GoG на рынке в прямом смысле не сравнима с конкурентами,
Ага. GoG в несколько раз отстаёт от Steam, но отрыв от всех остальных конкуретнов — так же велик, как GoG от Steam.
Также не могу не отметить, что если смотреть на трекерах, то игры с GoG появляются там буквально в нулевой день. То есть опасения издателей мягко говоря не беспочвенны.
А издателям, собственно, чего нужно — игру продать или с трекерами бороться?
Если игру — то GoG тут очень даже годится ибо там продажи всего лишь в 4 раза меньше, чем у Steam при том, что игр там продаётся сильно меньше, так что для каждой конкретной игры разница ещё меньше.
А если главное — борьба с трекерами, тогда да, тут GoG не помощник.
В данном случае конечно два понятия ("время жизни" и "область видимости") совпадают, но переменная может быть статичной, например, и тогда область видимости будет той же, а вот жить она будет до конца программы и никакой деструктор не вызовется.
Вызовется-вызовается. Ишшо как вызовется. Вы только полюбуйтесь сколько кода генерируется, чтобы он вызвался.
Аж прям память в __cxa_atexit аллоцируется, чтобы всё правильно вызвалось.
Вторая проблема C++ — этот язык не знает никто до конца.
О! Спешу вас обрадовать! Стараниями разработчиков компиляторов у C++ теперь паритет с C — ибо C, как его понимают современные компиляторы, тоже никто не знает до конца!
В моём представлении C++ это все же про создание и разрушение объектов во времени.
C++ (и Rust) — это про создание абстракций. Если у вас в проекте людей, способных это грамотно сделать, нету (или то, что вы пишите, слишком просто, чтобы требовать абстракций), то ни C++, ни Rust , действительно, не нужны.
Нижний слой хардверной абстракции стоит оставить на Сях.
Если это абстрации (любые), то C++ (или Rust) там уместен почти наверняка.
В принципе C++ и Rust идут в одну точку, но с разных сторон: C++ позволяет создавать удобные, красивые, но небезопасные абстракции — и, со временем, старается сделать их использование безопасным, а Rust — сразу говорит, что все абстракции должны быть безопасными или их не должно быть — но это приводит к тому, что некоторые вещи там вообще сделать нельзя ибо никто пока не придумал как их сделать безопасными.
Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит.
Вы не просто отстали от жизни, а очень сильно отстали.
Потому что C++ это уже очень давно не “OOP с наследованием и виртуальными функциями” это уже давным-давно очень малоиспользуемая часть C++ (хотя иногда оно бывает и нужно, но чаще нужны совсем другие вещи: RAII, метапрограммирование и т.д. и т.п.)
Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?
Существует ровно одна причина не использовать C++: у вас нет людей, которые его хорошо знают.
Хотя если вы всё ещё пользуетесь C, то я бы рекомендовал на Rust глянуть: пользы будет больше, а самая типичная причина продолжать использовать C++ (у нас куча библиотек на C++ и мы не хотим их переписывать) к вам не относится.
А то, что их можно при этом одинаково использовать, вроде нигде не написано?
Написано. В C89 написано вот это
If two pointers to object or incomplete types compare equal. they both are null pointers. or both point to the same object. or both point one past the last element of the same array object.
Четвёртый вариант (и связанное с ним безумие, когда у вас есть два равных указателя, но один можно использовать, а другой нельзя) появляется только в C99.
Об этом, мне, собственно, заявили прямо:
If you believe pointers are mere addresses, you are not writing C++; you are writing the C of K&R, which is a dead language. The address space is not a simple linear space: it is a time-varying disjoint sum of many small affine spaces, which the compiler maps to a linear address space (for common target triples!). This has been in the standards since C99 (although perhaps not very clear for those not versed in standardsese).
И про то, что безумие началось с C99 (попытки делались ещё при разработке C89, но Керниган, своим авторитетом, их отбил) и про то, что правила у нас явно не прописаны ни в одном стандарте (причём с точки зрения разработчиков компиляторов это небольшая проблема… не им же эти, нигде не описанные правила, соблюдать) и про многое другое — было сказано явно.
Рекомендация была такой:
Viewing C/C++ as static is a mistake. Viewing it as a portable assembler is a mistake. Viewing it as "GCC behaved this way last I checked, so it still holds, right?" is also a common mistake. It is important to stay up to date on the standards, be aware of what fussy code looks like (or, practically, what not-fussy code looks like), and know how to ask for help, as I have stressed in each of my previous replies.
Офигительный подход как для языка основное достоинство которого — тот факт, что на нём написаны миллиарды строк кода, не так ли?
Теоретически я ешё как-то могу применить этот подход, благо у нас есть и разработчики clang в компании и весь код регулярно прогоняется через новые его версии (те, которые ещё в разработке), но, блин, они реально хотят сказть, что все разработчики, использующие C/C++ должны подобным заниматься? Опираться даже не на стандарт, а на what fussy code looks like (or, practically, what not-fussy code looks like).
Да они оху…, нет, охр… да блин, как на это без мата-то реагировать?
Вообще-то можно, и именно потому, что компилятор про эти функции ничего не знает.
Это не определение корректной программы, извините. Корректная программа не должна зависеть от знания компилятором чего-либо и создавать объекты иначе как через malloc/calloc/realloc и удалять иначе как через realloc/free.
В C++ ещё new/delete появляются.
Проблема наступит в тот момент, когда эти функции станут известны компилятору ради очередных оптимизаций.
Совершенно верно, но это, собственно, и означает, что программа всегда была некорректной.
В общем, проблемы о того, что разработчики стандарта тихо-мирно поменяли смысл сравнения указателей с побитовой эквивалентности на логическую эквивалентность и под капотом сравнивают не все биты, чтобы заявить, что указатели одинаковые.
Если бы всё было так просто. Тут не в битах дело. Почитайте пропозал-то: они статически, во время компиляции, пытаются доказать, что некоторые указатели указывают на разные объекты в памяти.
И вот тут у них у самих неразбериха: в соотвествии с “креативным” прочтением правил указатель p протух, ладно, но p1 — это ж число, оно, вроде как, протухать не должно… или должно?
Серьезные проекты, прошивка роутера какого-нибудь уже на Java.
А пример можете привести? Потому что максимум чего я видел — Java-applet для управления и настроек. Но он на самом роутере не исполняется, он в браузере на компьютере работает. А так-то можно много чего записать в малинку, даже Windows, как известно, бывает и даже не только IoT. Но это тоже всё DIY.
А насчёт нормальных проектов… насколько оно на практике востребовано? Какая-нибудь статистика, подтверждающая ваши утверждения, есть?
Но где-то, конечно, ставят мелкие МК с десятками байт оперативной памяти и этого достаточно.
И тут тоже интересно: какой процент вот этого всего? Потому что есть ощущение, что цена 32-битных микроконтроллеров снизилась настолько, что 8-битные или там 4-битные больше смысла не имеют (в какой-то момент цена всё равно упирается в корпусировку и монтаж, так что ниже какой-то цены у вас никакой контроллер опуститься не может).
char heap[100500*1024]; — и откусывай оттуда своими аллокаторами.
В C++20 это сработает благодаря PR593. Только не забудьте правильные конструкторы/деструкторы вызывать. Конечно вы получите, таким образом не malloc/free, а new/delete, но для C++ этого хватает.
А вот в C (и более ранних версиях C++) — не получится, потому что нет никакого способа превратить кусок этого массива в объект другого типа и, главное, нельзя заставить этот объект перестать существовать.
Можно, наверное, работать только и исключительно с char'ами, но это, как бы сказать помягче, дико неудобно.
Опять же, это только проблема free/realloc, а реально пользуются API/фреймворками, в C++ вообще этого нет (нет realloc в парадигме new/delete — нет проблемы).
Конкретно этой проблемы нет, зато есть масса других. Одно существование std::launder — много говорит о масштабах разрухи.
Как я уже сказал: проблема не в том, что “правила игры”, навёрнутой вокруг этого всего, сложно соблюсти, проблема в том, что никто не может их даже внятно сформулировать!
Известно только, что то, что прописано в стандарте — это “не то”, то есть соблюдения стандарта при написании программ — недостаточно.
P.S. С точки зрения нормальных людей было бы разумно, понятно, трактовать все эти эффекты консервативно, разрешая оптимизации в отдельных местах, помеченных как-нибудь особо. Но тогда упадёт скорость на бенчмарках, а этого разработчики компиляторов, конечно, допустить не могут. Но чёрт бы с ними, дали бы ключик -fno-provenance (как уже дали -fno-strict-aliasing)… но нет, не хотят. Слишком сложно, говорят. А избегать-того-не-знаю-чего — раз плюнуть, да?
Интересно.
Вот с этого момента поподробнее. Возьмём, к примеру, бухгалтерию, где понятия “счёт” и “счёт-фактура” имеют между собой мало общего и, главное, первое понятие существует в англоязычных странах, а второе — отстстует и потому разные переводчики (человеческие, не машинные) его переводят по разному.
Как ваш прозрачно-переводчик решит эту проблему? Особенно когда особый термин — внутренний для предприятия?
Хорошо, если так. Скорее всего он заканчивается на проходной, отделющий его отдел от соседних.
Собственно он и показывает как Роскосмосу удаётся достичь, даже без формального распила и откатов (они, возможно, и есть, но это, при такой организации, и неважно), одновременно двух достижений:
Фантастической стоимости всего, связанного с Роскосмосом.
Чудовищно низких зарплат у большинства работников.
А всё просто: если объявить, что у нас тут космос, всё супер-пупер уникальное, сделано под заказ и, условно говоря, вытачивать каждый болт на отдельном, созданом конкретно для этого болта станке и писать программы для каждого блока на отдельном, разработанном специально для этого блока, языке программирования… ооо… тут можно освоить любые средства́ и ещё мало будет.
Прям такой заповедник позднего СССР живой.
Очень даже понятно по имя чего. Такой поход, когда, условно, цех левых тапочек понятия не имеет по какой технологии выпускаются правые тапочки не позволяет никого сократить. Ибо никто ни с кем не взаимозаменяем.
Ну почитайте же Паркинсона, он прекрасно всё описал.
А что — офис после этого стали меньше покупать? А если нет — зачем тратить деньги на что-то, что не приносит прибыли?
Я прекрасно помню, что подавляющему большинству игроков ни номера Игромании, ни интернет были недоступны даже в начале XXI века.
А уж в прошлом веке это всё было доступно хорошо, если одному игроку из ста.
У нас в школе был Интернет, да, но когда кто-то попытался скачать несколько патчей для каких-то игр и выжрал квоту всей школы за месяц…
В общем игры для которых были нужны патчи были, скорее, редкими исключениями, чем правилом.
Уж не знаю о каких годах вы говорите, но на PlayStation и PlayStation2 были десятки JRPG — и я не знаю ни одной, которую нельзя было бы пройти без каких-либо патчей. Troika Games выпускала игры для Windows, потому ситуация “если игра будет непроходима, то придётся отозвать весь тираж и, скорее всего, обанкртиться” им была незнакома.
Это всё PC игры. Они начали портится быстрее чем консольные. По двум причинам: с начала века начало сильно диверсифицироваться железо, но, главное, появилась возможно выпускать сырые недоделки и потом — бесконечные патчи для них.
Не были. В том-то и дело, что не были. Графика была не на порядак, а на два проще — это да. А вот геймплей у многих PlayStation2 игр вполне себе не уступал современным, кое в чём даже превосходил.
Да, PlayStation2 — это вершина “неотзывных” игр, Xbox даже первый, как тут выше подсказали, кое-где уже начал скатываться в выпуск поделок, которые можно играть только через год после “оффициального релиза”, но это как раз и показывает, что причина всей этой бажности не в какой-то особой сложности современных игр, а банально в том, что выпуск бажных игр не приводит к диким убыткам.
А это было в эру до того, как консоли начали массово подключать к Интернет.
До Xbox (оригинального), PlayStation2 и Wii.
И вы знаете что? Писали. И игры работали. Да, ошибки были и тогда, но критичные до релиза не доживали и мешать не играли.
Да, разработака занимала дольше, но и сейчас многие игры разрабатываются по 3-4 года. Что мешает ещё полгода потратить на то, чтобы найти все критические баги и исправить?
Если вы скачате оригинальную версию, то её на современной системе фиг запустишь.
В GOG версии, на самом деле, немного изменений — только то, что какие-то борцуны с насилием в играх их через суд заставили вырезать.
Если у вас нет ретрокомпьютера, то проще Fallout Fixt и FO2 Restoration патчи накатить, чем пиратку искать.
Учитывая то, что вы понятия не имеете о чём говорите, думаю обсуждать бессмысленно, но…
Ага. GoG в несколько раз отстаёт от Steam, но отрыв от всех остальных конкуретнов — так же велик, как GoG от Steam.
А издателям, собственно, чего нужно — игру продать или с трекерами бороться?
Если игру — то GoG тут очень даже годится ибо там продажи всего лишь в 4 раза меньше, чем у Steam при том, что игр там продаётся сильно меньше, так что для каждой конкретной игры разница ещё меньше.
А если главное — борьба с трекерами, тогда да, тут GoG не помощник.
Вызовется-вызовается. Ишшо как вызовется. Вы только полюбуйтесь сколько кода генерируется, чтобы он вызвался.
Аж прям память в __cxa_atexit аллоцируется, чтобы всё правильно вызвалось.
О! Спешу вас обрадовать! Стараниями разработчиков компиляторов у C++ теперь паритет с C — ибо C, как его понимают современные компиляторы, тоже никто не знает до конца!
C++ (и Rust) — это про создание абстракций. Если у вас в проекте людей, способных это грамотно сделать, нету (или то, что вы пишите, слишком просто, чтобы требовать абстракций), то ни C++, ни Rust , действительно, не нужны.
Если это абстрации (любые), то C++ (или Rust) там уместен почти наверняка.
В принципе C++ и Rust идут в одну точку, но с разных сторон: C++ позволяет создавать удобные, красивые, но небезопасные абстракции — и, со временем, старается сделать их использование безопасным, а Rust — сразу говорит, что все абстракции должны быть безопасными или их не должно быть — но это приводит к тому, что некоторые вещи там вообще сделать нельзя ибо никто пока не придумал как их сделать безопасными.
Вы не просто отстали от жизни, а очень сильно отстали.
Потому что C++ это уже очень давно не “OOP с наследованием и виртуальными функциями” это уже давным-давно очень малоиспользуемая часть C++ (хотя иногда оно бывает и нужно, но чаще нужны совсем другие вещи: RAII, метапрограммирование и т.д. и т.п.)
Существует ровно одна причина не использовать C++: у вас нет людей, которые его хорошо знают.
Хотя если вы всё ещё пользуетесь C, то я бы рекомендовал на Rust глянуть: пользы будет больше, а самая типичная причина продолжать использовать C++ (у нас куча библиотек на C++ и мы не хотим их переписывать) к вам не относится.
Лучше отдельным. Потому что это действительно очень важно, но это, в общем, совсем другой тип статьи будет.
Конечно можно. В Rust лучше сделано. Но это всё добавляли уже когда была куча кода написана.
Вот тут есть статья, объясняющая почему и как перемещение сделано в C++ и в Rust.
Вы хотя бы примерно, представляете сколько серы уже и так ТЭЦ и ТЭС выбрасывают? А вулканы?
Вы физически не сможете закинуть сравнимое количество в стратосферу.
Другое дело, что, ровно по этой же причине, вряд ли удастся и эффекта остужения добиться заметного.
Да, вы правы, у меня, похоже, сбой godbolt был.
Это, кстати, типичная ситуация для “малого” embedded, где собирается не программа, а прошивка.
И где компилятор, действительно, при использовании LTO знает всё про всю программу.
Написано. В C89 написано вот это
Четвёртый вариант (и связанное с ним безумие, когда у вас есть два равных указателя, но один можно использовать, а другой нельзя) появляется только в C99.
Об этом, мне, собственно, заявили прямо:
И про то, что безумие началось с C99 (попытки делались ещё при разработке C89, но Керниган, своим авторитетом, их отбил) и про то, что правила у нас явно не прописаны ни в одном стандарте (причём с точки зрения разработчиков компиляторов это небольшая проблема… не им же эти, нигде не описанные правила, соблюдать) и про многое другое — было сказано явно.
Рекомендация была такой:
Офигительный подход как для языка основное достоинство которого — тот факт, что на нём написаны миллиарды строк кода, не так ли?
Теоретически я ешё как-то могу применить этот подход, благо у нас есть и разработчики clang в компании и весь код регулярно прогоняется через новые его версии (те, которые ещё в разработке), но, блин, они реально хотят сказть, что все разработчики, использующие C/C++ должны подобным заниматься? Опираться даже не на стандарт, а на what fussy code looks like (or, practically, what not-fussy code looks like).
Да они оху…, нет, охр… да блин, как на это без мата-то реагировать?
Это не определение корректной программы, извините. Корректная программа не должна зависеть от знания компилятором чего-либо и создавать объекты иначе как через malloc/calloc/realloc и удалять иначе как через realloc/free.
В C++ ещё new/delete появляются.
Совершенно верно, но это, собственно, и означает, что программа всегда была некорректной.
Если бы всё было так просто. Тут не в битах дело. Почитайте пропозал-то: они статически, во время компиляции, пытаются доказать, что некоторые указатели указывают на разные объекты в памяти.
И вот тут у них у самих неразбериха: в соотвествии с “креативным” прочтением правил указатель p протух, ладно, но p1 — это ж число, оно, вроде как, протухать не должно… или должно?
Вот если оба указателя превратить в числа, а потом обратно — clang, наконец-то, перестаёт издеваться над здравым смыслом. Но это законно или нет? Почитайте к чему все эти попытки ведут.
Правил нет, но вы держитесь. В смысле — их соблюдайте.
А пример можете привести? Потому что максимум чего я видел — Java-applet для управления и настроек. Но он на самом роутере не исполняется, он в браузере на компьютере работает.
А так-то можно много чего записать в малинку, даже Windows, как известно, бывает и даже не только IoT. Но это тоже всё DIY.
А насчёт нормальных проектов… насколько оно на практике востребовано? Какая-нибудь статистика, подтверждающая ваши утверждения, есть?
Ну и, понятно, есть ещё такая штука как размытие самого понятия Embedded. Формально же компьютер Tesla, на котором Cyberpunk 2077 бегать может - тоже embedded, но там кроме этого компьютера ещё десяток других, попроще.
А на первых пентиумах Java игрушкой была. То есть, в те времена, даже офисные пакеты на Java пытались портировать, только не взлетело это нифига.
И тут тоже интересно: какой процент вот этого всего? Потому что есть ощущение, что цена 32-битных микроконтроллеров снизилась настолько, что 8-битные или там 4-битные больше смысла не имеют (в какой-то момент цена всё равно упирается в корпусировку и монтаж, так что ниже какой-то цены у вас никакой контроллер опуститься не может).
Я знаю только про прикольное сравнение микроконтроллеров из USB-зарядок с компьютером Apollo, но там, всё-таки, не самые дешёвые контроллеры пользуют.
Потому что C - это не C++.
В C++20 это сработает благодаря PR593. Только не забудьте правильные конструкторы/деструкторы вызывать. Конечно вы получите, таким образом не
malloc/free, аnew/delete, но для C++ этого хватает.А вот в C (и более ранних версиях C++) — не получится, потому что нет никакого способа превратить кусок этого массива в объект другого типа и, главное, нельзя заставить этот объект перестать существовать.
Можно, наверное, работать только и исключительно с
char'ами, но это, как бы сказать помягче, дико неудобно.Конкретно этой проблемы нет, зато есть масса других. Одно существование std::launder — много говорит о масштабах разрухи.
Как я уже сказал: проблема не в том, что “правила игры”, навёрнутой вокруг этого всего, сложно соблюсти, проблема в том, что никто не может их даже внятно сформулировать!
Известно только, что то, что прописано в стандарте — это “не то”, то есть соблюдения стандарта при написании программ — недостаточно.
P.S. С точки зрения нормальных людей было бы разумно, понятно, трактовать все эти эффекты консервативно, разрешая оптимизации в отдельных местах, помеченных как-нибудь особо. Но тогда упадёт скорость на бенчмарках, а этого разработчики компиляторов, конечно, допустить не могут. Но чёрт бы с ними, дали бы ключик -fno-provenance (как уже дали -fno-strict-aliasing)… но нет, не хотят. Слишком сложно, говорят. А избегать-того-не-знаю-чего — раз плюнуть, да?