Здравствуйте, 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 как платформы исполнения разрабатываемых программ.

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

В общем, это сейчас улеглось малость...
Но эти ваши хейтерские страсти объективно вредили индустрии примерно с конца 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 как платформы исполнения разрабатываемых программ.

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

В общем, это сейчас улеглось малость...
Но эти ваши хейтерские страсти объективно вредили индустрии примерно с конца 90-х.