Как перейти с новомодных недоязычков на православные C/C++?

Это другое!

а чем это таким эти ваши модули намазаны, что на них слетаются как мухи?

Тем что определяют область видимости и позволяют чётко указать что откуда используется, а не помойка Си где все объявления во всех заголовках собираются в одну кучу.

Надо было gcc main.c globals.c globals.h

Надо было gcc globals.c main.c

gcc main.c:

Надо gcc globals.c main.c.

Сколько в расте разных типов указателей? Я насчитал 5. Это даже больше, чем в C++ (raw, unique_ptr, shared_ptr, weak_ptr).
По мне так Раст посложнее C++ будет.

Кто-нибудь уже перешёл на C++ ?

Но C++ действительно сложен ИЗЛИШНЕ именно для пользователей. Надо брать простой и логичный язык, например haskell.

Надо брать простой и логичный язык, например haskell.

Это не язык общего назначения.

Любой полный по Тьюрингу язык достаточно универсален, чтобы иметь возможность имитировать любой другой

Я про общее назначение в практическом смысле. Компьютер физически работает на императивной основе и функциональное программирование не позволяет эффективно его использовать.

Наоборот. Только функциональное программирование позволяет как следует использовать многопоточное оборудование.

как следует

И как же следует? Наверное, с боксингом на каждый чих? Или с блокирующим гц?

На самом деле есть ещё проблема: в сишке нужно вручную дрочиться с выделением памяти. Особенно если из функции нужно вернуть что-то сложнее числа. Я не могу сделать просто возврат переменной типа char*, нужно обязательно выделить память. В новомодном недоязычке я просто могу вернуть string.

Это решается сторонними библиотеками, STC, например.

Проникнуться красотой того, что открыв заголовочный файл, ты можешь читать интерфейс «модуля» без мусора деталей реализации.

проникся…

шаблоны С++

отникся :)

С/С++ ужастные ЯП, это надо просто накрепко запомнить и не касаться их даже шестифутовой палкой.

зачем смешивать два абсолютно разных языка?.. C – монстр, порождённый самыми тёмными глубинами заблудшего разума… C++ – удобоваримый язычок начиная со стандарта 14/17… :)

Ты хаскел видел? Там же всё построено на иммутабельности.

Заголовочные файлы (ака хидеры), строго говоря, можно и не создавать, если тебе не нужно делить описания и типы между модулями (короче, если в данном конкретном случае раздельная компиляция тебе не сильно и нужна). Т.е. в какой-либо условной библиотеке у тебя может быть один хидер, описывающий необходимый и достаточный внешний интерфейс, а в main.c

#include "something1.c"
#include "something2.c"
...

Будет как один большой, но исходник, разбитый на несколько логически законченных модулей.

Как перейти с новомодных языков на C/C++ и перестать бомбить с описанных в посте проблем?

Взять и писать, учитывая особенности. Как-будто в них собственных проблем сильно меньше. И да, согласен с выше написанным, это не сказать, чтобы проблемы.

C++ – удобоваримый язычок начиная со стандарта 14/17

Ну, видимо вы сильно умней меня, который забил пытаться понимать кресты, начиная с 11-го стандарта. Как по мне, написать на этом франкенштейне что-то корректное не вляпавшись по пути в ограничения/вольные трактования стандарта или в парочку UB, могут уже «не только лишь все» (с).

Если я вместо executable напишу execurable — какое сообщение об ошибке я получу?

забил пытаться понимать кресты, начиная с 11-го стандарта

Ну по совести говоря, for по контейнерам — весьма полезная штука. :)

В новомодном недоязычке я просто могу вернуть string.

Ну тогда C++ — тоже новомодный недоязычок :)

На одну ложку мёда, 100500 ложек … стандарта. И формула «пользуйтесь только теми возможностями, которые вам нужны» перестаёт работать, как только в проектах появляется сторонний код (особенно от каких-нибудь ценителей творчества Александреску). А, следовательно, в любом случае надо помнить +- все актуальные на данный момент стандарты.

Просто не надо стараться использовать «все возможности стандарта». В C++ есть 1000 и один способ выстрелить себе в ногу, достаточно изучить один, но хорошо :)

Кстати, я тут вспомнил, что в новомодных язычках можно прям в исходниках писать некие теги, чтобы потом сгенерировать из них документацию. Можно ли прикрутить такое к сишке - я не знаю, но видел список функций из некоторых проектов прям онлайн. Это к вопросу об отсутствии разделения на заголовочники и исходники. Во всяком случае, в Rust это вроде как удобно сделано. Хоть я и не пишу на расте.

Просто не надо стараться использовать «все возможности стандарта»

Ну вот выше написал: это хорошо, когда весь код собственный (ну ладно, одной команды с чётким требованием к коду). А когда в проекте появляется сторонний код («чувак, давай интегрируем вот ту классную библиотеку/модуль/сервис/etc.») - начинается приключение, особенно, если там фанаты какого-нибудь Александреску (ехал шаблон через шаблон, прихватив итератор и вот ту «классную фичу», описанную в какой-то ж. стандарта).

В любом случае приходится не знать, так помнить, как работать примерно со всеми фичами, всех актуальных стандартов. У меня от этого немного плавится и мозг и стул :)

В C++ есть 1000 и один способ выстрелить себе в ногу

«Это была не нога» сказал он и густо покраснел :)

Можно ли прикрутить такое к сишке

man doxygen

Как перейти с новомодных недоязычков на православные C/C++?

Никак. Если ты начал с модных недоязычков, то твой мозг безнадежно испорчен.

Про Rust может больше рассказать anonymous-angler.

Чем именно испорчен и почему?

Можно ли прикрутить такое к сишке - я не знаю

doxygen же

Схрена ли golang, созданный авторами Си и позиционируемый как «си на стероидах» вдруг стал новомодным недоязычком?

ps. аватара у тебя блевотная.

Я создал заголовочный файл, в котором хранились глобальные (для всего приложения) значения.

Ну, как обычно, профессионал уровня lor не в курсе разницы между определением и объявлением — но виноват, разумеется, язык.

(У меня как-то был типа коллега — университетский препод, поэтому считал себя офигенным профессионалом и вообще очень умным. Наваял модуль, в котором аккуратно все определения засунул в заголовочный файл. Причём возражений не принимал и править код не давал — у него-то «работает» с его стабом, а то, что проект с добавленным его модулем даже не компилится — мои проблемы. Переписывать мне не упиралось, так как для этого надо было лезть в его сферу специализации. Долго же я извращался, заворачивая это говно в разные врапперы, чтоб не воняло…)

Есть такое

Не инклуд stdlib и пусть твои волосы будут мягкими и шолковистыми

Схрена ли golang, созданный авторами Си и позиционируемый как «си на стероидах» вдруг стал новомодным недоязычком?

Сишники так говорят. На ЛОРе, в том числе.

построено на иммутабельности.

Не имеет отношения к многопоточности.

Ты хаскел видел?

Да. А ты видел, во что он компилируется?

На С вляпаться в них куда проще.

позиционируемый как «си на стероидах»

Он не позиционируется так.

Да и с stdlib так очень даже можно жить, особенно после введения polymorphic allocators.

https://habr.com/ru/company/vk/blog/327966/
Один из лекторов Техносферы обозвал golang именно так.

Какое отношени лекторы Техносферы имеют к Go?

Используют в продакшн, и довольно умело. Этого мало?

Да, мало. Они могут использовать что угодно и где угодно. Авторы Go его так не позиционируют и таким не считают.

Да не сказал-бы. Конкретно на мой вкус: Си как раз простой, как валенок (даже в новых стандартах). В этом его плюс, т.к. объять одним мозгом проще, и в этом же минус - на каждую потребность надо топтать кнопки, оформлять в либы, к которым писать тесты.

В плюсах регулярно приходится думать: что там наперегружали выше, во что там развернётся очередная шаблонная лапша, какие побочные эффекты в очередных креативах STL, чё там очередной тридвараз накастовал (в сишке хотя бы сразу видно) … короче много чего надо думать, помнить и учитывать. Гораздо больше, чем в Си-шке. Где я одно время работал даже шутили, что плюсы, чем дальше тем больше - это язык теоретиков и практика в нём уже давно закончилась.

Да и вообще я ООП не люблю (хотя порой он полезен, не спорю, но сплошь и рядом это ООП-ради-ООП, что тоже отдельный вид маразма).

В cppfront есть такое: https://github.com/hsutter/708/blob/main/708.pdf. Ещё такое встречается в виде аннотаций в плюсовом коде.

in соответствует & в расте, inout соответствует &mut, смартпоинтеры же везде одни и те же.

Вторая - заголовочные файлы. Как-то раз, давно, я писал простенькое приложение. Я создал заголовочный файл, в котором хранились глобальные (для всего приложения) значения. Подключаю его в нескольких .cpp файлах - линкер ругается, не может он что-то там слинковать. Добавляю в заголовочник #pragma once - компилятор ругается, что у многих .cpp нет к нему доступа. Бомбанул, перестал писать. Конечно, жопы прожжёных сишников и крестовиков и не такое видали, но я не выдержал.

потому что не понимаешь, как это работает под капотом.

#include это чисто текстовая вставка. вставить можно любой текст в любой другой текст. после того, как все вставлено в исходник, он компилируется. поскольку вставлется текст, то если во вставляемом файле есть дефиниция переменной например, типа

int XX = 100;

то такая переменная будет вставлена во все файлы куда сделан include, что приводит к тому, что линкер видит несколько XX и ругается, поскольку это определение нескольких обьектов с однгим именем.

потому в хидерах описываются не переменные, а «обьявления об их существовании» в виде extern int XX, что говорит, что мол существует «внешняя», к месту куда будет вставлен этот файл, переменная XX.

надо отличать «декларации» от «размещения» или «реализации».

декларация обьявляет о существовании. размещение выделает память под обьект, реализация содержит код реализумого обьекта.

extern int XX - это декларация внешней глобальной переменной, компилятор память не выделит, но будет считать, что такая переменная будет найдена при сборке линкером и в код в нужных местах будет подставлен адрес переменной. если линкер такое имя не найдет - он ругнется что не найден такой обьект

int XX - это размещение переменной (компилятор выделит память в нужном месте). обращаться к переменной нельзя, до ее декларации или размещения, поскольку компилятор не знает ее типа, потому он ругнется.

int func(); - декларация функции, нужна чтобы скомпилировать ее вызов, не зная ее кода. таким образом достигается «раздельная компиляция». чтобы в одном файле вызывать некие фукции, которых в нем нет, можно просто проинклудить в него заголовки функций… или эти заголовки ручками написать, что то же самое(вот чтобы ручками не писать и сделали include).

int func(){…} - реализация функции

чтобы скомпилировать код вызова функции нужен ее заголовок, поскольку нужно точно знать список аргументов, - их типы, порядок и число.

опять же в силу полиморфизма в с++, могут существовать функции с одинаковым именем, но разными аргументами. от есть понять(не имея деклараций) как скомпилировать my_fun(10) - невозможно, поскольку таких my_fun может быть несколько, с разными типами параметров, да еще и с дефолтными значениями.

в виде аннотаций в плюсовом коде.

Это не «плюсовый» код, а MS-ные SAL и SAL2, используемые для С и С++. К языку это отношения не имеет.

Да банальный stl полистать достаточно.

Эти недоязычки <…> без кодогенерации

Не подскажете, как на С или С++ можно быстро сериализовывать/десериализовывать объекты из JSON/YAML? Хочется удобства на уроне Rust’овского serde.

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

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

На github из коробки это не посмотреть, но для более/менее живых проектов документация уже сгенерированна и доступна в web. В том числе на централизованных сайтах.

Локально работать со всем этим барахлом еще удобнее: вся документация по зависимостям под рукой со встроенным поиском.