Модули

если

Да что за калл из тебя прёт?!

Вот столько лет прошло, а ты русский язык так и не выучил. Позорище!

Можно. Но после такого действа, вопросов зачем нужны модули уже не должно возникать :)

В C++ есть namespace’ы. (В Python, конечно, круче механизм)

В С++ есть, да, но в Си нет. Но и namespace не решает всех проблем и не заменяет модули.

Либо кодишь на С, либо на С++, но не на этом дебильном гибриде с strcpy и кастами (type).

Бессмысленный и беспощадный фошизм какой-то :)

сообщил парамошка лингвисту.

наелся?

Ты-то — лингвист? Ну не надо же так смешить!

А вообще, не понимаю, почему тебя терпят модераторы и не трут твои сообщения с преднамеренным коверканием русского языка.

Зачем ждать?

git clone git://gcc.gnu.org/git/gcc.git
cd gcc
mkdir build
cd build
../configure --prefix=${HOME}/usr # тут надо ещё всякие там mpc и mpfr указать где они
make -j8
make install

и не забыть добавить в PATH, CPATH, LD_LIBRARY_PATH, и MAN_PATH свою ${HOME}/usr/XXX

Потому что тогда недостатки одного суммируются с недостатками другого, а преимущества - нивелируются.

дак и ты не парамоша.

Или наоборот.

Не надо пересказывать услышанные где-то «умные» мысли, тем более затирать про бСССР. Этот стиль - один из самых популярных в C++ во всем мире, и не без причин.

// Сам пишу не так, но понимаю тех кто не может/не хочет иначе.

ты ведь не сразу за мой язык уцепился

только после ….

первые твои реплики(а) были в рамках пояснения своей позиции

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

Давайте будем мужчинами. И если выясняем что-то между собой то не будем взывать к модераторам и пытаться их настроить против неугодного собеседника. Модераторы тоже люди и могут легко в порыве накативших эмоций и подлитого маслица в огонь забанить зря кого-то. Я понимаю что вам этого только и надо но все же вы носите штаны а не юбку. Так соответствуйте.

https://m.youtube.com/watch?v=jN6_rO2rYA8

Ну и чем от этого «модульность» отличается? Где цимус?

Делать подпроекты? Никогда не даелал статические либы для них?

не даелал статические либы

Уточняем: «статические либы» - это действительно либы? или это тупо архивы объектников?

Под «либами» много чего можно понимать. Бывают, например, header-only библиотеки (stb, например). А часть своих часто используемых сниппетов я вообще как динамическую библиотеку оформил (потому что замучился в 100500 велосипедах согласовывать последние изменения внутри всех этих сниппетов: исправишь баг в одном месте или фичу добавишь, и ковыряйся потом…).

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

в тебе говорит зависть к.

Мне проще тебя в игнор добавить!

сочувствую.

сочувствую.

Кому? Себе, чтоле? Глупец! Ты жалок!

без модулей ваще не жизнь, так существование

Лорчую. Причем независимо от языка и платформы.

Нет еще. Частично везде, по уму нигде.

продолжаешь поглощать.

https://en.cppreference.com/w/cpp/language/modules

мне это напоминает javascript

очередная конвергенция в Кенорленд

Чем же? Словами import/export?

Да, динамически загружаемые модули *.so/*.dll в Си есть. Но интеграция с языком плохая.

«Цимус» в том, что твой draw.h включается в другие файлы как ТЕКСТ. Можешь сам проверить: возьми и руками замени include «draw.h» на содержимое самого файла. Скомпилируется без проблем. То есть, draw.h не компилируется вообще.

А отсюда всякие вредные штуки. Если ты напишешь в draw.c #define MY_COOL_MACROS 1 перед #include, а внутри draw.h используется MY_COOL_MACROS — то в draw.o (или draw.obj) у тебя MY_COOL_MACROS будет 1, а в других он будет считаться неопределённым. Что, конечно, круто для всяких хаков, но легко приводит к головной боли, особенно если от этого макроса зависит интерфейс «модуля» draw.c.

Модули — штука гораздо более устойчивая. Если модуль скомпилирован, то любой, кто его импортирует, будет видеть один и тот же интерфейс, гарантированно, а потому на этапе выполнения не будет неожиданностей с этой стороны.

Модули — штука гораздо более устойчивая. Если модуль скомпилирован, то любой, кто его импортирует, будет видеть один и тот же интерфейс, гарантированно, а потому на этапе выполнения не будет неожиданностей с этой стороны.

В си делается все ручками. Грузим через dlopen, и вперед. :)

Давайте будем мужчинами.

будь мужчиной, пиши все в одном файле без модулей

Бред. Если мне нужно подключать какие-то внешние функции я линкуюсь с динамической библиотекой. И никакие модули мне не нужны!

Коллизия имён функций из различных библиотек

Не стандарт языка, но я лично считаю, что библиотеки должны собираться с -fvisilibty=hidden по умолчанию. Другое дело, что не всегда им можно воспользоваться.

Либо кодишь на С, либо на С++, но не на этом дебильном гибриде с strcpy и кастами (type).

Cи с классами – это вполне приемлемый вариант как по мне. Конечно без strcpy и сишных кастов, но ты понимаешь к чему я клоню.

Так называемый Modern С++ это какой-то эзотерический язык. И то я наверное обидел этим любителей эзотерических языков.

Если хочешь си с модулями, то бери PHP. Скорость как си плюс ооп и модули. Сейчас на PHP, даже, VR движки разрабатывают.

Рукалицо….

Ты вообще прочитал, на что отвечаешь?

А это нормально работает в случе, если вообще ничего неизвестно о библиотеке и файлов-загловков нет?

А это нормально работает в случе, если вообще ничего неизвестно о библиотеке и файлов-загловков нет?

Если интерфейс к модулю неизвестен, то да, будут проблемы. Там типы меток не передаются, надо их знать заранее. Ну такой себе c-style.

Теперь гораздо проще: просто поставь новую Федору.

Стрелять за такое нужно. С/С++. Это разные языки и схожесть названий не должна смущать.

Это еще что. Некоторые обезьяны С от C# отличить неспособны.

С другой стороны, написать на Си код, который соберется компилятором С++ хотя бы возможно. В этом смысле выбор названия С++ вполне оправдан. В отличие от C#, который с Си действительно не имеет ничего общего. Просто кто-то решил попаразитировать на известном названии.