Здравствуйте, Sinclair, Вы писали:

V>>Это ты еще про модули не видел:
V>>https://habr.com/ru/company/yandex_praktikum/blog/554874/
V>>Это еще не мейнстрим, но как GCC 11 попадёт в основные сборки Linux и выйдет релизная VS 2022 — будет мейнстримом.
S>Ага, не видел. Пока что выглядят неюзабельно — с таким подходом им ещё лет десять до минимально приемлемого уровня ползти. Но молодцы, что наконец вынули голову из того места, где она была, и начали хоть как-то догонять нынешний стандартный уровень.

Компиляция в модули — двоякоострая технология.
Экономя на повторной компиляции файлов (хотя, и с этим сейчас эффективно борются), она требовательна к объёму оперативки, т.е. как в нулевых на линухах с 500MB юзер-спейса не взлетит.

Она требует компиллируемости всего и сразу, что не всегда удобно в случае лохматых зависимостей м/у проектами одной разработки разработки, т.к. не позволяет работать независимо над отдельными cpp-файлами, как это принято сейчас — в процессе разработки разработчик периодически вызывает компиляцию только тех cpp-файлов, над которыми в данный момент работает.

То бишь, в нынешней схеме можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, всё-таки, разработка любой нетривиальной системы взаимодействующих сущностей часто идёт сверху вниз, т.е. подробности всё более окучиваются на последующих итерациях разработки.

Не зря в хелперах/рефакторах Джава и C# чуть ли не первой функциональностью идёт генерирование пустых методов-заглушек — как раз борются с описанными сценариями.
Это удобно, но это ловушка, бо интерфейсы многих базовых вещей порой заставляют в наследниках обильно рассыпать "Not implemented.." вовсе не по причине забывчивости.
В плюсах в этом сценарии будет ошибка линковки, т.е. будет хорошо видно, что именно еще не реализовано.


S>Но при наличии выбора, я предпочитаю платформу, которая разработчика уважает.

Слабая демагогия, не торкает. ))

Платформа настолько уважает, что пакетный менеджер Nuget вышел спустя ~15 лет после выхода дотнета.


S>В которой заранее потрачены усилия на то, чтобы новичок мог быстро начать приносить пользу

ПХП!


S>Не вижу никакого смысла гордиться тем, что "да я в ваши годы шёл по гололёду от проходной до нашего подвала три километра в гору и против ветра, работал за чугунной клавиатурой, сидя в валенках, а ссать ходил во двор в дыру в стене".

"В наши годы" (С) происходило чуть другое характерное — цена ошибки была выше, а совершить её было проще.


S>Надо стремиться к лучшему.

Напомню, что мы рассуждали конкретно о кроссплатформенной сборке.
Так вот, линусятки угомонились со свои хейтерством только примерно в 2012-м году.

До этого задаче "кроссплатформенность" порой выдавали не просто низкий приоритет, а строго отрицательный, — многие проекты специально разрабатывались так, чтобы не быть в два шага доступными на виндах.

И вот ты из 2021-го пытаешься взять проект нулевых и удивляешься, а что это у нас с кроссплатформанностью???
Там примерно то же, что плюсовики слышали от джава и шарп девелоперов в адрес нейтивного программирования.
Только здесь в адрес Windows как платформы разрабатываемых программ.

И основные работы по одновременному покрытию широкого круга платформ выполнялись в рамках коммерческих проектов, бо опенсорс был фактически неумолим насчёт маздая. ))
Это сейчас страсти улеглись малость...
Но эти ваши хейтерские страсти объективно вредили индустрии в конце 90-х и все нулевые.

Здравствуйте, Sinclair, Вы писали:

V>>Это ты еще про модули не видел:
V>>https://habr.com/ru/company/yandex_praktikum/blog/554874/
V>>Это еще не мейнстрим, но как GCC 11 попадёт в основные сборки Linux и выйдет релизная VS 2022 — будет мейнстримом.
S>Ага, не видел. Пока что выглядят неюзабельно — с таким подходом им ещё лет десять до минимально приемлемого уровня ползти. Но молодцы, что наконец вынули голову из того места, где она была, и начали хоть как-то догонять нынешний стандартный уровень.

Компиляция в модули — двоякоострая технология.
Экономя на повторной компиляции файлов (хотя, и с этим сейчас эффективно борются через pch), она требовательна к объёму оперативки, т.е. как в нулевых на линухах с 500MB юзер-спейса не взлетит.

Она требует компиллируемости всего и сразу, что не всегда удобно в случае лохматых зависимостей м/у проектами одной разработки, т.к. не позволяет работать независимо над отдельными cpp-файлами, как это принято сейчас — в процессе разработки разработчик периодически вызывает компиляцию только тех cpp-файлов, над которыми в данный момент работает.

То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве.
В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами.
Т.е. даже если в архитектуре конечного продукта половина из них и нафик не упёрлась, но без них невозможно эффективно распараллеливать разработку. ))

В общем, не зря в хелперах рефакторинга Джава и C# чуть ли не первой функциональностью идёт генерирование пустых методов-заглушек — как раз борются с описанными сценариями.
Это удобно, но это ловушка, бо интерфейсы многих базовых вещей порой заставляют обильно рассыпать в наследниках "Not implemented.." вовсе не по причине забывчивости.
В плюсах в этом сценарии будет ошибка линковки, т.е. будет хорошо видно, что именно еще не реализовано.


S>Но при наличии выбора, я предпочитаю платформу, которая разработчика уважает.

Слабая демагогия, не торкает. ))

Платформа настолько тебя уважает, что пакетный менеджер Nuget вышел на боевую готовность спустя ~15 лет после выхода дотнета.


S>В которой заранее потрачены усилия на то, чтобы новичок мог быстро начать приносить пользу

ПХП!


S>Не вижу никакого смысла гордиться тем, что "да я в ваши годы шёл по гололёду от проходной до нашего подвала три километра в гору и против ветра, работал за чугунной клавиатурой, сидя в валенках, а ссать ходил во двор в дыру в стене".

"В наши годы" (С) происходило чуть другое характерное — цена ошибки была выше, а совершить её было проще.
Ну и, худшее обращение знаний в индустрии, в итоге меньшее кол-во общедоступных полезных библиотек и т.д. до бесконечности.


S>Надо стремиться к лучшему.

Напомню, что мы рассуждали конкретно о кроссплатформенной сборке.
Так вот, линусятки угомонились со свои хейтерством только примерно к 2012-му.
До этого задаче "кроссплатформенность" порой выдавали не просто низкий приоритет, а строго отрицательный, — многие проекты разрабатывались с полным игнором возможности собирать их под виндой. ))

И вот ты из 2021-го пытаешься взять проект нулевых и удивляешься, а что это у нас с кроссплатформанностью???

А там примерно то же, что плюсовики слышали от джава и шарп девелоперов в адрес нейтивного программирования.
Только здесь прямое хейтерство в адрес Windows как платформы исполнения разрабатываемых программ.

И основные работы по одновременному покрытию широкого круга платформ выполнялись в рамках коммерческих проектов, бо опенсорс был фактически неумолим насчёт маздая. ))
Это сейчас страсти улеглись малость...
Но эти ваши хейтерские страсти объективно вредили индустрии примерно с конца 90-х.