Большой минус С++ - C/C++

Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.
1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

Может быть данные проблемы уже как-то решены, но я об этом не знаю ?
Если нет, может сделать предкомпилятор, который из одного файла (где объявление и реализация) создаст 2 файла h+cpp, которые будут компилироваться.

>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?
Модули?

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

M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

#define желательно не использовать лишь в пределах одной единицы трансляции, т.к. это может сломать ODR.
И вообще желательно обойтись другими средствами метапрограммирования. Шаблоны, constexpr функции, if constexpr...

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

M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.

Включать они друг друга явно не могут, значит, могут использовать по указателю/ссылке. Для этого достаточно сделать forward declaration для одного из этих классов

M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

Нет такой проблемы. Если define объявлен в cpp после инклудов, то это явно какой-то локальный define. Если макрос определён в хидере — то он явно предназначен для использования где угодно. С макросами только одна проблема — у них нет пространств имён. Это решается просто длинным именем с префиксом модуля/библиотеки etc. Макросы же, которые определяют конфигурацию сборки — обычно никто не задаёт в cpp файлах, они передаются компилятору в командной строке. Еще вариант, когда таких макросов много — запихать их в один хидер, и сказать компилятору сделать preinclude данного файла — т.е. включать его перед всем остальным для каждой единицы трансляции

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?

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

M>Если нет, может сделать предкомпилятор, который из одного файла (где объявление и реализация) создаст 2 файла h+cpp, которые будут компилироваться.

Можно, но зачем?

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

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

Мелкие функции имеет смысл писать в заголовках для инлайнинга, а для больших дублирование объявлений не даёт заметную проблему.

M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.

Ещё можно сделать абстрактный класс с нужными функциями в роли интерфейса.

M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

Если это не что-то радикальное вроде макры RB_PROTOTYPE, то const/constexpr выгоднее тем, что имеет пространство имён.
Если радикальное, ему можно дать имя с длинным префиксом и затем #undef в конце заголовочника.

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?

А это проблемы? Ну я понимаю, что половина использующих C++ реально пишет на "C с классами", но это как-то не очень тематично...

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
Вы счастливый человек.

M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
Как же мучаются писатели составляя оглавление и предметные указатели.

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

Современные IDE умеют одним кликом мышки заводить новые классы, добавлять новые функции и члены класса сразу и в хедерах и в исходниках. Так же переименовывать сразу во всех исходниках (у них это в разделе "Рефакторинг" в выпадающем меню)

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

В смысле писать ?
Сегодня любые IDE это делают за вас.
Пишете один раз в заголовке и в один щелчок появляется заготовка в cpp файле.
Также если нужно изменить прототип, меняем один раз, а IDE уже сама поменяет везде, где надо.

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

_>Как же мучаются писатели составляя оглавление и предметные указатели.

так в системах вёрстки здорового человека (latex например) оглавление и предметные указатели формируются автоматически.

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

SP>так в системах вёрстки здорового человека (latex например) оглавление и предметные указатели формируются автоматически.
Ага после нескольких проходов

M>Современные IDE умеют одним кликом мышки заводить новые классы, добавлять новые функции и члены класса сразу и в хедерах и в исходниках. Так же переименовывать сразу во всех исходниках (у них это в разделе "Рефакторинг" в выпадающем меню)

Это да:
1) часто на сервере нужно править исходники. Там только текстовый терминал.
2) современные IDE, часто имеет проблемы если использовать макросы или шаблоны.
3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.
4) И намного удобнее когда 1 файл = 1 класс.

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

Для меня основной минус C# от которого хотелось бы избавиться — это чудовищная организация кода.
Открываешь файл — там класс на 1K+ строчек, и понять, что вообще там за методы или свойства есть — никакого способа нет, кроме как исследовать код через IDE (при чём во всех это сделано через неудобно).

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

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

M>>Современные IDE умеют одним кликом мышки заводить новые классы, добавлять новые функции и члены класса сразу и в хедерах и в исходниках. Так же переименовывать сразу во всех исходниках (у них это в разделе "Рефакторинг" в выпадающем меню)

M>Это да:
M>1) часто на сервере нужно править исходники. Там только текстовый терминал.
Берём VSCode поверх SSH.
Или VIM/NeoVIM с плагинами.

M>2) современные IDE, часто имеет проблемы если использовать макросы или шаблоны.
M>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.
Все IDE умеют горячие клавиши и работу с клавиатурой.
К тому же везде ещё есть и режим VIM если очень нужно.

M>4) И намного удобнее когда 1 файл = 1 класс.
Ну это вам язык менять надо. C/C++ так не работают.

M>>4) И намного удобнее когда 1 файл = 1 класс.
_NN>Ну это вам язык менять надо. C/C++ так не работают.

только тем кто не освоил модули из С++20

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

M>>>4) И намного удобнее когда 1 файл = 1 класс.
_NN>>Ну это вам язык менять надо. C/C++ так не работают.

R>только тем кто не освоил модули из С++20

Расскажите в каком компиляторе они работают без проблем ?
https://en.cppreference.com/w/cpp/compiler_support/20

плохому танцору....

Я с этим столкнулся еще в 1992 году...

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

MA>Открываешь файл — там класс на 1K+ строчек, и понять, что вообще там за методы или свойства есть — никакого способа нет, кроме как исследовать код через IDE (при чём во всех это сделано через неудобно).

в студии Ctrl M + O Collapse To Definitions. Получаем просто h файл.

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

R>плохому танцору....

Я так понимаю это лишь бы сказать.

Вы лично с модулями работаете или работали ?
Вот попробуйте и покажите нам как хорошо компиляторы их поддерживают.

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

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?

Это чего за детский лепет я сейчас прочитал? Вон из профессии

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

SP>>так в системах вёрстки здорового человека (latex например) оглавление и предметные указатели формируются автоматически.
_>Ага после нескольких проходов

Ну ты же не сам ногами их делаешь десятикилометровыми кругами

Бро, я в кейле, сидя на пыхтящем роботе, бьющем гусеницой, на ходу правлю баги и отлаживаю прошивку. А ты — терминал, терминал...

M>2) современные IDE, часто имеет проблемы если использовать макросы или шаблоны.

Или не имеют. Тут рядом тема была, что IDE вообще не нужны

M>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.

Клав хоткеи обычно есть для почти всего. И IDE при наборе сама тебе всё покажет, кнопками выбирать успевай

M>4) И намного удобнее когда 1 файл = 1 класс.

И что мешает? Открой для себя class forward declarations и inline out-of-class member functions

У меня практически во всех проектах даже для STM — только один файл .cpp — main.cpp. Может, ты плохо умеешь в C++?

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

MA>>Открываешь файл — там класс на 1K+ строчек, и понять, что вообще там за методы или свойства есть — никакого способа нет, кроме как исследовать код через IDE (при чём во всех это сделано через неудобно).

SP>в студии Ctrl M + O Collapse To Definitions. Получаем просто h файл.

Когда ты зашел по SSH и запустил 'nano'

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

M>>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
LVV>

LVV>Я с этим столкнулся еще в 1992 году...

И что, никак не растолкнуться?

M>>4) И намного удобнее когда 1 файл = 1 класс.
_NN>Ну это вам язык менять надо. C/C++ так не работают.

Зачем язык менять ? Проще сделать предкомпилятор, который будет создавать cpp/h из одного файла.
Неужели нет такого ещё ?

M>И что мешает? Открой для себя class forward declarations и inline out-of-class member functions

M>У меня практически во всех проектах даже для STM — только один файл .cpp — main.cpp. Может, ты плохо умеешь в C++?

Я же написал.
1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.
С class forward declarations ты только через ссылки или указатели класс сможешь использовать, что не всегда приемлемо.
С одним cpp будет поностью компилиться весь проект при любом изменении!

M>>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
LVV>

LVV>Я с этим столкнулся еще в 1992 году...

Я тоже уже давно, что удивительно столько лет прошло и никак эта проблема НЕ решается

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

M>>И что мешает? Открой для себя class forward declarations и inline out-of-class member functions

M>>У меня практически во всех проектах даже для STM — только один файл .cpp — main.cpp. Может, ты плохо умеешь в C++?

M>Я же написал.
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.

Ты, видимо, просто плохо знаешь C++

M>С class forward declarations ты только через ссылки или указатели класс сможешь использовать, что не всегда приемлемо.

Ты какую-то дичь несёшь. Ты никак не сможешь сделать что-то типа:

class A
{
    int   m_a;
    B     m_b;
};

class B
{
    int   m_b;
    A     m_a;
};

Ну вот вообще никак.

По любому, один из классов будет только ссылаться на другой, ссылка или указатель — это уже детали. Более того, я чего-то сомневаюсь, что в каком-либо языке такое вообще возможно

M>С одним cpp будет поностью компилиться весь проект при любом изменении!

Это работает только при уже устоявшихся интерфейсах модулей/библиотек. Когда разрабатываешь модуль/библиотеку — и интерфейс и реализация постоянно меняется. И никто не мешает выносить интерфейсы (в виде абстрактных классов) в отдельные хидеры. Разделение на h/cpp хорошо работает, только когда уже все интерфейсы устоялись. И вот тогда и имеет уже смысл разделить один файл на h/cpp. Тут любая IDE всё сделает за тебя в несколько кликов

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.
M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?
M>Если нет, может сделать предкомпилятор, который из одного файла (где объявление и реализация) создаст 2 файла h+cpp, которые будут компилироваться.

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

Есть ещё виртуальные методы. При оверрайде их в классах наследниках приходится повторно прописывать те же аргументы по несколько раз. И при изменении в базовом классе тянуть все изменения везде. Более того это не обязательно должны быть именно виртуальные методы. В моём одном проекте есть набор классов, имеющих набор статических методов с одинаковым именем и прототипом. В этом случае приходится пользоваться поиском-заменой — и я считаю это уже "гемор".

В си++ не хватает такой штуки, как прототип функции. Но хочется некоторые прототипы иметь связанными с именем функции, некоторые с типами и именами аргументов + тип возвращаемого значения, а некоторые — только аргументы.

Второе.
При использовании модулей отпадает необходимость в .h файлах и инклюдах. Всё можно делать только в .cpp
Кроме дифайнов — их нельзя экспортировать из модулей. Вот их как раз и можно выносить в .h

Вот тут есть неплохое описание как с ними работать: https://itnext.io/c-20-modules-complete-guide-ae741ddbae3d

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

PCH, которые тянут всю лапшу во весь проект, больше не нужны.

p.s. Но не всё так гладко. С модулями придётся указывать вручную порядок компиляции .cpp файлов. Ведь пока нет готовой системы, которая определяет их зависимости (как это делает скажем code::blocks с инклюдами, чтобы перекомпилировать только изменённые файлы). Надеюсь, что это временно так.

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

M>>>4) И намного удобнее когда 1 файл = 1 класс.
_NN>>Ну это вам язык менять надо. C/C++ так не работают.

M>Зачем язык менять ? Проще сделать предкомпилятор, который будет создавать cpp/h из одного файла.
M>Неужели нет такого ещё ?

Никому не надо, все осилили то, что есть. Если не осилил — сделай. Хотя ты и это не осилишь

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

M>>>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>>>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
LVV>>

LVV>>Я с этим столкнулся еще в 1992 году...

M>Я тоже уже давно, что удивительно столько лет прошло и никак эта проблема НЕ решается

Просто никто не видит в этом никакой проблемы

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

S>Хочется поддержать топик стартера. Тут дело даже не в том, что бывает надо выносить реализацию метода извне класса и прописывать повторно имена аргументов и их типы.

Поддержать — это зря

S>Есть ещё виртуальные методы. При оверрайде их в классах наследниках приходится повторно прописывать те же аргументы по несколько раз. И при изменении в базовом классе тянуть все изменения везде. Более того это не обязательно должны быть именно виртуальные методы. В моём одном проекте есть набор классов, имеющих набор статических методов с одинаковым именем и прототипом. В этом случае приходится пользоваться поиском-заменой — и я считаю это уже "гемор".

S>В си++ не хватает такой штуки, как прототип функции. Но хочется некоторые прототипы иметь связанными с именем функции, некоторые с типами и именами аргументов + тип возвращаемого значения, а некоторые — только аргументы.

Мысль здравая. Только прототипы функций уже термин застолблённый. Это скорее как прототип функции как тип, который можно указать constraint'ом для функции/метода.
Можешь проработать идею и написать в комитет, раз уж всё равно дурака валяешь

S>Второе.
S>При использовании модулей отпадает необходимость в .h файлах и инклюдах. Всё можно делать только в .cpp
S>Кроме дифайнов — их нельзя экспортировать из модулей. Вот их как раз и можно выносить в .h

Модули — не нужны

S>p.s. Но не всё так гладко. С модулями придётся указывать вручную порядок компиляции .cpp файлов. Ведь пока нет готовой системы, которая определяет их зависимости (как это делает скажем code::blocks с инклюдами, чтобы перекомпилировать только изменённые файлы). Надеюсь, что это временно так.

Помню, в своё время была тема с extern template'ами — говна я покушал, больше не хочу. Вот будет C++ 26, в котором модули доведут до нормального состояния — тогда и поговорим

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

SP>в студии Ctrl M + O Collapse To Definitions. Получаем просто h файл.
Визуально оно шумит. Кроме того, я достаточно часто что-нибудь ищу в коде, простыми средствами. Например в FAR. Как в C++, так и в C#. Да вообще в любом коде. Пока ты знаешь что найти и метод работает в лоб — то почему бы его не использовать?
Я в целом говорю, про ситуации, когда я освеломлен о <1% кода в принципе. И как ни странно, очень часто — в C++ оказывается легче, т.к. из всего — как правило, легко выделить публичный контракт. Новая библиотека? У нее есть публичные хидеры. Даже не прибегая к глубокому анализу, можно прикинуть кол-во сущностей.
Публичный контракт из C# или Java получить совершенно точно не представляется возможным, пока вы не выполните работу компилятора.

Другое дело, что если надо изменть/расширить код — то в C++ резко становится сложнее (по сравнению с C#), но не потому, что код организован таким образом, а потому что в проекте может быть разное число компонентов (библиотек), в каждой — свой строковой тип данных (при чем осмысленный, а не наследие 90-х) или еще какие-то особенности, о которых,как правило, даже не догадываешься, не погрузившись глубже. Плохого в этом ничего нет, но, требуется хотя бы небольшое погружение не сколько в специфику проекта, а сколько в его окружения и его правила.

В общем, это всё лично мое мнение и не более. Самые отвратительные в плане организации/структуризации/оформления — проекты которыми я только сталкивался (я молчу про свои, они ессно в топе идеальности, если считать до плинтуса), то это .NET CLR (сам рантайм / C++) и V8 с которым я провел немало ночей, пока разобрался почему в GC течет память. V8 прям аккуратен, по сравнению с CLR, но против материнского проекта — он просто безобразен. При этом всем, в .NET BCL (C#) — если не знаешь где искать — найти ничего найти нельзя в принципе, часто надо еще изучить и сам проект, что б понять откуда берутся методы/свойства в partial типах и вообще кто здесь. Кроме того там куча солюшенов, поэтому, для быстрого сёрфинга IDE, которая начнет зачем-то в фоне устанавливать пакеты — категорически не годится в принципе (это я про фолдинг). Фолдинг — это про один класс.
В реальности — в проектах — есть одна директория куда навалено по заветам FDG — т.е. все в одну кучу, и если вы это видите все в первый десяток раз — то никакие средства IDE — не помогут, не говоря уже о том, что IDE нужна когда нужна но не более. А если код логически расформирован — то внезапно уже и IDE не нужна что бы понять что и где. А если есть публичные хидеры — то вообще знакомство происходит не с основания горы с миллионом незначащих подробностей — а с вершины.

Я собственно говоря, не топлю ни за один ни за другой способ. Просто вижу преимущества и первого и второго. Преимущества второго (наличия хидеров) для меня открылись только в последние <10 лет. А 20 лет назад я был восхищен тем, что в C# нп нужно писать эти дурацкие хидеры.

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
Вообще это плюс. В хидере у тебя интерфейс, в сишнике имплементация.

И это не дублирование, дублирование, когда у тебя одинаковые имплементации в 10 разных местах скопипасчены.

M>Ты какую-то дичь несёшь. Ты никак не сможешь сделать что-то типа:
M>

M>class A
M>{
M>    int   m_a;
M>    B     m_b;
M>};

M>class B
M>{
M>    int   m_b;
M>    A     m_a;
M>};
M>

M>Ну вот вообще никак.

А если так

class B;

class A
{
    int   m_a;
    B*     m_b;
};

class B
{
    int   m_b;
    A*     m_a;
};

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

M>Никому не надо, все осилили то, что есть. Если не осилил — сделай. Хотя ты и это не осилишь

Что с тобой случилось? Почему от тебя на форуме столько негатива? Ты чем-то болеешь?

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

M>>Ну вот вообще никак.

V>А если так
V>

V>class B;

V>class A
V>{
V>    int   m_a;
V>    B*     m_b;
V>};

V>class B
V>{
V>    int   m_b;
V>    A*     m_a;
V>};
V>

Так — можно. И?

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

M>>Никому не надо, все осилили то, что есть. Если не осилил — сделай. Хотя ты и это не осилишь

TB>Что с тобой случилось? Почему от тебя на форуме столько негатива? Ты чем-то болеешь?

От меня? Много негатива? Это ты ещё не видел ответы reversecode'а

Но вообще — какие-то через-чур наивные вопросы, от человека, который сто лет тут обитает и пишет на плюсах

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

S>Есть ещё виртуальные методы. При оверрайде их в классах наследниках приходится повторно прописывать те же аргументы по несколько раз. И при изменении в базовом классе тянуть все изменения везде. Более того это не обязательно должны быть именно виртуальные методы. В моём одном проекте есть набор классов, имеющих набор статических методов с одинаковым именем и прототипом. В этом случае приходится пользоваться поиском-заменой — и я считаю это уже "гемор".

Откройте для себя IDE и инструменты рефакторинга.
Скажем Visual Studio, Resharper C++, CLion, и т.д.
Одним щелчком меняются сигнатуры всех наследников.

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

MA>>>Открываешь файл — там класс на 1K+ строчек, и понять, что вообще там за методы или свойства есть — никакого способа нет, кроме как исследовать код через IDE (при чём во всех это сделано через неудобно).

У C++ практически та же проблема при большом количестве inline методов, определённых внутри класса.
Выносить эти определения отдельно... можно, конечно, поставить такое стилевое условие, но может быть жестковато.

SP>>в студии Ctrl M + O Collapse To Definitions. Получаем просто h файл.

M>Когда ты зашел по SSH и запустил 'nano'

nano сношу везде, где всерьёз работаю, и ставлю joe. А у него уже есть Ctrl+G для поиска парной скобки.
Ну и разумеется vim ('%' для того же действия).
Это уже кое-что — хотя придётся попрыгать по всем методам.

Вообще для решения таких задач без IDE придуманы всякие ctags, etags... они делают список, который можно просто просмотреть глазами, а можно в редакторе подключать и использовать для позиционирования на нужную функцию (метод). Внутрь классов и неймспейсов они давно научились заглядывать.

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

MA> Публичный контракт из C# или Java получить совершенно точно не представляется возможным, пока вы не выполните работу компилятора.

Хм, как правило в этих обоих языках _публичный_ контракт выделяют в виде сущности типа interface. По крайней мере так ну очень рекомендуется. А уже отнаследоваться от интерфейса — сделать реализацию — можно и только на нужные методы.

Конечно, никто не заставляет так делать, и внутри пакетов на это поплёвывают.

(А ведь интерфейсы, в этом смысле, и есть аналоги заголовочников C/C++.)

MA> В реальности — в проектах — есть одна директория куда навалено по заветам FDG — т.е. все в одну кучу,

Реально есть такой завет?

MA> и если вы это видите все в первый десяток раз — то никакие средства IDE — не помогут, не говоря уже о том, что IDE нужна когда нужна но не более. А если код логически расформирован — то внезапно уже и IDE не нужна что бы понять что и где.

Ну при определённом уровне сложности с IDE таки в разы легче

MA> А если есть публичные хидеры — то вообще знакомство происходит не с основания горы с миллионом незначащих подробностей — а с вершины.

MA> Я собственно говоря, не топлю ни за один ни за другой способ. Просто вижу преимущества и первого и второго. Преимущества второго (наличия хидеров) для меня открылись только в последние <10 лет. А 20 лет назад я был восхищен тем, что в C# нп нужно писать эти дурацкие хидеры.

Я конечно извиняюсь, и не придирка, но: https://dictionary.cambridge.org/dictionary/english/header

header
UK /ˈhed.ər/
US /ˈhed.ɚ/

Ну нету там "и".

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

M>Но вообще — какие-то через-чур наивные вопросы, от человека, который сто лет тут обитает и пишет на плюсах

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

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

N>Я конечно извиняюсь, и не придирка, но: https://dictionary.cambridge.org/dictionary/english/header

N>header
N>UK /ˈhed.ər/
N>US /ˈhed.ɚ/

N>Ну нету там "и".

И нас много

M>По любому, один из классов будет только ссылаться на другой, ссылка или указатель — это уже детали. Более того, я чего-то сомневаюсь, что в каком-либо языке такое вообще возможно

Ты себя крутым считаешь, всех хаишь — сам бред полный написал. Такое невозможно скомпилировать, так возникает бесконечная вложенность в данных.
Я вот что имеел ввиду:

class B;

class A {
public:
void DoSomething() {
m_v = B::GetV();
}
private:
int m_v;
};

class B {
public:
static int GetV() { return 1; }
void DoSomething() {
A a; a.DoSomething();
}
};

Вот такой код не получается скомпилировать, если не выносить функции в другой файл. На строку "m_v = B::GetV()" gcc ругается.
Хотя я не понимают, почему gcc не хочет в 2 этапа это сделать:
1) сначала пробежаться и составить объявления всех классов и функций
2) скомпилировать функции

class B;

class A {
public:
void DoSomething() {
m_v = B::GetV();
}
private:
int m_v;
};

class B {
public:
static int GetV() { return 1; }
void Do() {
A a; a.DoSomething();
}
};

Может я что-то не понимаю ?

V>Вообще это плюс. В хидере у тебя интерфейс, в сишнике имплементация.

Да, только все современные языки такие как C#, Java ушли от этого "так называемого плюса".

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

M>>По любому, один из классов будет только ссылаться на другой, ссылка или указатель — это уже детали. Более того, я чего-то сомневаюсь, что в каком-либо языке такое вообще возможно

M>Ты себя крутым считаешь, всех хаишь — сам бред полный написал. Такое невозможно скомпилировать, так возникает бесконечная вложенность в данных.

Ты еще и читать не умеешь

M>Я вот что имеел ввиду:

M>

M>class B;

M>class A {
M>public:
M>    void DoSomething() {
M>        m_v = B::GetV();
M>    }    
M>private:
M>    int m_v;
M>};

M>class B {
M>public:    
M>    static int GetV() { return 1; }
M>    void DoSomething() {
M>        A a; a.DoSomething();
M>    }    
M>};
M>

И в чем проблема? Описал отдельно классы, сделал реализацию. Тут вообще нет никаких проблем

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

m> V>Вообще это плюс. В хидере у тебя интерфейс, в сишнике имплементация.

m> Да, только все современные языки такие как C#, Java ушли от этого "так называемого плюса".

Миллионы мух не могут ошибаться!

avalon/3.0.0

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

M>И в чем проблема? Описал отдельно классы, сделал реализацию. Тут вообще нет никаких проблем

Ну вот вынесеш ты тело метода отдельно — будет одна проблема читать (объявление отдельно, определение отдельно, причём в этом примере после объявлений обоих классов A и B).
Нет — будет другая (слишком много определений в основном предложении class).
Что так плохо, что так плохо.
Потому и говорят, что сворачивание в IDE тут самое полезное. Но и в нём нужны переходы из объявления к телу и наоборот.

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

M>Вот такой код не получается скомпилировать, если не выносить функции в другой файл. На строку "m_v = B::GetV()" gcc ругается.
M>Хотя я не понимают, почему gcc не хочет в 2 этапа это сделать:
M>1) сначала пробежаться и составить объявления всех классов и функций
M>2) скомпилировать функции
a)

class B;

class A {
public:
    void DoSomething();
private:
    int m_v;
};

class B {
public:
    static int GetV() { return 1; }
    void Do() {
        A a; a.DoSomething();
    }
};

void A::DoSomething() {
    m_v = B::GetV();
}

struct B0 {
    static int GetV() { return 1; }
};

struct A {
    void DoSomething() {
        m_v = B0::GetV();
    }
private:
    int m_v;
};

struct B : B0 {
    void Do() {
        A a; a.DoSomething();
    }
};

M>Может я что-то не понимаю ?
Возможно стоит вопрос сформулировать точнее. Что именно вас не устраивает?

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

M>Может я что-то не понимаю ?

Порядок объявлений принципиален:

void f(long){}

void g(){
f(1) вызовет f(long)
}

void f(int){} добавляем перегрузку

void h(){
f(1) теперь будет f(int)
}

M>Так — можно. И?
M>Ну вот вообще никак.

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

M>>Так — можно. И?
M>>Ну вот вообще никак.

Это не так, про что я говорил, что никак не сделать

M>Да, только все современные языки такие как C#, Java ушли от этого "так называемого плюса".
Ты еще про современный жабаскрипт забыл и еще кучу модного смузихлебного.
В отличие от всего этого модного С и С++ хотя бы логичны и последовательны.

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

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

Ещё в C++ трудно, неудобно делать PIMPL-идиому, т.к. либо получается фабрика классов,
либо все потроха класса и, главное, все зависимости выезжают в заголовочный файл.

M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.

Не нужно. Нужно сделать forward declaration для класса и лучше вообще
писать код так, что не A использует B, а что A использует некую абстракцию
которой в итоге удовлетворяет B, но A про B ничего непосредственно не знает,
и наоборот, B про A, а только про необходимую абстракцию. Тогда абстракции
могут быть предварительно декларированы и могут быть начаты использованы
без знания о самих A или B.

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

Главное при работе с C++ -- это изменить своё мышление. C++ имеет другие методы
решения задач, чем языки вроде Java, Delphi, C#. Методы не существующие в этих языках.
А подходы применимые в других языках хоть в C++ и работают, но выглядят часто хуже.

И не нужно программу на C++ превращать в программу на FORTRAN, где всё впихнуто
в один мега-класс зависящий абсолютно от всего чего только возможно. Не нужно
стесняться разделять логику на множество простых абстракций с простыми и минимальными
зависисмостями. Такие абстракции просты, легко проверяемы, в них трудно допустить ошибку.
Их можно отдельно и независимо протестировать. А мегакласс -- это типичный спагетти-код
со всеми его "преимуществами".

При работе с шаблонами нужно не забывать, что не обязательно всё должно попасть в
заголовочмный файл, иногда можно пользоваться extern template.

M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

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

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

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?

Да нет на самом деле никакой проблемы...

M>Если нет, может сделать предкомпилятор, который из одного файла (где объявление и реализация) создаст 2 файла h+cpp, которые будут компилироваться.

Модули в C++20, но вряд ли оно сильно чем-то поможет.

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

M>>Современные IDE умеют одним кликом мышки заводить новые классы, добавлять новые функции и члены класса сразу и в хедерах и в исходниках. Так же переименовывать сразу во всех исходниках (у них это в разделе "Рефакторинг" в выпадающем меню)

M>Это да:
M>1) часто на сервере нужно править исходники. Там только текстовый терминал.

Это ж замечательно, что там текстовый терминал. Значи там работает лучший
в мире редактор Vim, в котором быстро всё можно сделать. Ну или Emacs если
кому-то Vim претит.

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

M>2) современные IDE, часто имеет проблемы если использовать макросы или шаблоны.

Это проблема "современынх IDE", а не макросов или шаблонов. В Vim никаких с этим проблем.

M>4) И намного удобнее когда 1 файл = 1 класс.

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

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

M>Я же написал.
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.
M>С class forward declarations ты только через ссылки или указатели класс сможешь использовать, что не всегда приемлемо.
M>С одним cpp будет поностью компилиться весь проект при любом изменении!

https://en.wikipedia.org/wiki/Dependency_inversion_principle

fk0> Абстракция в коде может быть воплощена либо в абстрактном базовом классе,
fk0>либо в шаблоне. В большинстве случаев более рационален подход с шаблоном, так
fk0>как даёт связывание/диспетчеризацию в момент компиляции, а не в момент исполнения.
fk0>Кроме того, в момент разворачивания шаблона он обладает полнотой знания о переданном
fk0>ему классе-параметре, что тоже может использовать и что не доступно в варианте
fk0>с наследованием.

У меня большой опыт как на с/с++, так и на c#.
На c# намного удобнее читать/писать бизнес логигу (или другую логику, где много разных сущностей и классов), так как не приходиться лазить по 2-м файлам, а всё можно исправить и увидеть в одном файле.
Хотелось бы иметь возможность на с++ такую же как на c#.
Использование абстракций и шаблонов, что-бы описать всё в одном файле, сильно усложнит код — это не то!
c# — это современный язык, в котором учли, что более удобно иметь 1 файл, чем 2. Не пойму, почему с++ не хочет дать такую возможность ? Оставить возможность h/cpp тем кому нравиться это и для совместимости.


class B;

template <typename B> class A_
{
    // If you uncomment this line and other commented line
    // in class B compilation fails:
    // B data[sizeof(B)];
    
public:
    // This function will be compiled after template instantiation,
    // and complete definition of the class defined by template.
    //
    // Template instantiation is delayed until template first time used.
    void DoSomething()
    {
        m_v = B::GetV();
    }
    
private:
    int m_v;
};

using A = A_<B>;

class B
{   
    // If you uncomment this line and other commented line
    // in class B compilation fails:
    //A bb;
    
    // This compilation failure caused by the fact that line
    // listed above causing template instantiation, but 
    // template can't be instantiated if it requires knowledge
    // of sizeof(B), as class B currently is not fully defined.
    
public:
    static int GetV() { return 1; }
    
    // But this function will be compiled only after finishing definition
    // of class B.
    void DoSomething()
    {
        // Template will be instantiated after compiler sees this line.
        A a;
        a.DoSomething();
    }
};

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

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

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

MA>Для меня основной минус C# от которого хотелось бы избавиться — это чудовищная организация кода.
MA>Открываешь файл — там класс на 1K+ строчек, и понять, что вообще там за методы или свойства есть —

Вот для этого-то в C++ и есть заголовочные файлы!

А то заладили, модули, модули. И будет то же самое. И, кстати, в C# есть понятие .ref
файлов и в них те же "хедеры". В студии по F11/F12 оно кстати показывать их умеет...

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

S>Есть ещё виртуальные методы. При оверрайде их в классах наследниках приходится повторно прописывать те же аргументы по несколько раз. И при изменении в базовом классе тянуть все изменения везде.

А если бы ты так не делал, то как компилятор бы отличал виртуальные методы от других
перегруженных функций с тем же именем? А никак. Тогда нужно забыть об ADL (argument
dependent lookup). А это важное свойство C++ которого нет у многих других.

S>В си++ не хватает такой штуки, как прототип функции.

Forward declaration для функции возможен. Вот tentative declarations для переменных нет.
Какие проблемы?

S>Второе.
S>При использовании модулей отпадает необходимость в .h файлах и инклюдах. Всё можно делать только в .cpp
S>Кроме дифайнов — их нельзя экспортировать из модулей. Вот их как раз и можно выносить в .h

Нет. Я не понимаю, как с этим в модулях, но некоторые вещи же принципиально
не являются кодом. Например шаблоны. Как шаблон может быть в CPP, какой в этом смысл?
Шаблон -- это сущность лежащая в своём совершенно ортогональном пространстве шаблонов,
которое ортогонально пространствам типов и "вещественных" объектов таких как переменные
и функции.

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

M>У меня большой опыт как на с/с++, так и на c#.
M>На c# намного удобнее читать/писать бизнес логигу (или другую логику, где много разных сущностей и классов), так как не приходиться лазить по 2-м файлам, а всё можно исправить и увидеть в одном файле.

Во-первых не в одном. Там есть partial классы и потом концов не найдёшь, не то, что не в одном
файле, а вообще непонятно даже в какой DLL-ке...

Во-вторых чем оно удобно, когда есть файл на 50000 строк и там всё вперемешку.
Без IDE по такому файлу навигация невозможна, а если ты код поменял, пока редактировал,
что он стал синтаксически некорректным (скобок не хватает), то и IDE развалится и
перестанет работать... Сомнительное удобство.

И наконец, повторюсь, в C# есть .ref файлы и студия по F11/F12 что-то такое показывает.
Наподобие хедеров. Удобно на самом деле.

M>Хотелось бы иметь возможность на с++ такую же как на c#.

Пустяковый вопрос. Весь код пишешь в хедер-файле. И будет как в C#.

M>Использование абстракций и шаблонов, что-бы описать всё в одном файле, сильно усложнит код — это не то!

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

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

M>c# — это современный язык, в котором учли, что более удобно иметь 1 файл, чем 2.

Абсолютно любую C++-программу можно вообще записать в ОДНОМ ФАЙЛЕ. Просто тупо
склеить файлы. Разделение на файлы лишь для удобства человека и раздельной компиляции.

M> Не пойму, почему с++ не хочет дать такую возможность ? Оставить возможность h/cpp тем кому нравиться это и для совместимости.

Потому, что она объективно практически не нужна. И как не хочет -- про модули разговор
который год. Но в них смысл немного другой, избавиться от многократного парсинга скорей.
Так как с раздельной компиляцией в C++ реально плохо, из-за того, что половина кода в хедерах.

M>>Хотелось бы иметь возможность на с++ такую же как на c#.

fk0> Пустяковый вопрос. Весь код пишешь в хедер-файле. И будет как в C#.

Нет, не будет он компилиться. Я привёл код выше который не компилируется без шаблонов и прочих хитростях.
Вот он
http://www.rsdn.org/forum/cpp/8161507.1

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

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

Будет, достаточно определить функцию несколько позднее — https://ideone.com/mHO8nA

class A {
public:
    void DoSomething();
private:
    int m_v;
};
 
class B {
public:
    static int GetV() { return 1; }
    void Do() {
        A a; a.DoSomething();
    }
};
 
void A::DoSomething() {
    m_v = B::GetV();
}
 
int main() {
    return 0;
}

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

M>>>Хотелось бы иметь возможность на с++ такую же как на c#.

fk0>> Пустяковый вопрос. Весь код пишешь в хедер-файле. И будет как в C#.

M>Нет, не будет он компилиться. Я привёл код выше который не компилируется без шаблонов и прочих хитростях.
M>Вот он
M>http://www.rsdn.org/forum/cpp/8161507.1

Дело не в файлах, а как раз в "прочих хитростях". А во-скольки файлах оно всё записано
как раз дело десятое.

Можно в одном файле вначале:

1) декларировать класс;
2) потом отдельно записать определения функций.

И всё сразу начнёт компилироваться. Всё дело только в том, в каком порядке всё вынужден
обрабатывать компилятор. Если код писать как есть -- то начале "компилируется" класс, а потом
его функции. И в этот момент выясняется, что B -- неизвестная вещь. Если код фунцкии записать
отдельно, после класса, и после определения B -- всё получится. А шаблон позволяет сделать
то же самое, но неявным образом: финт в том, что шаблон компилятором не компилируется в код
до момента первого его использования. Поэтому внутри шаблона можно написать какой-то код,
но он не вызовет вопросов в момент интерпретации самого шаблона до момента пока шаблон
не превратиться в класс. И второй момент: все функции класса компилируются после того как
класс полностью определён. Вот и всё что нужно знать.

От файлов зависит что-то только для C-кода где полагаются на глобальные static-переменные.
Но они вообще не нужны, для этого существуют неймспейсы. Да, есть подводный камень -- анонимный
(без имени) неймспейс один на весь файл.

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

Резюмируя: хедеры -- это удобно, так как виден интерфейс. Если кому-то неудобно потому,
что там какой-то очень развесистый интерфейс, то скорей вы делаете что-то очень плохое
в архитектурном плане и менять нужно используемые архитектурные паттерны, а не требовать
чего-то от языка. Единственной реальной проблемой на мой взгляд является очевидное неудобство
реализации PIMPL-идиомы, но оно вытекает в значительной степени из-за того, что компилятор должен
знать layout класса и, главное, его sizeof. Может быть, имеет смысл такой финт ушами, когда
конструктор в PIMPL спрятан таки за фабрикой класса, но при этом предоставляется кастомный
аллокатор со стороны вызывающей стороны...

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

M>>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
LVV>

LVV>Я с этим столкнулся еще в 1992 году...

Я чуть раньше столкнулся... но в 1994 растолкнулся — перешел на Дельфи

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

M>1) часто на сервере нужно править исходники. Там только текстовый терминал.

Шта?

Какой сервер? К чему он указан? Мы точно про С++ говорим?)

M>2) современные IDE, часто имеет проблемы если использовать макросы или шаблоны.

Если мы говорим про современные — то не часто, крайне нечасто. Причём если проблемы есть — то там ещё под вопросом проблемы логики автора.

M>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.

Все ИДЕ имеют хоткеи, дублирующие функциональность мышки. И серьёзно — упомянутая разница в скорости работы с мышкой\клавиатурой в процессе разработки не важна в принципе.

M>4) И намного удобнее когда 1 файл = 1 класс.

Это говорит только о небольшом опыте работы с С++. Есть свои ньюансы. В большинстве случаев всё же удобнее разделение по файлам из-за анонимных неймспейсов и управлением вложениями классов.

Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс.

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

S>>Второе.
S>>При использовании модулей отпадает необходимость в .h файлах и инклюдах. Всё можно делать только в .cpp
S>>Кроме дифайнов — их нельзя экспортировать из модулей. Вот их как раз и можно выносить в .h

fk0> Нет. Я не понимаю, как с этим в модулях, но некоторые вещи же принципиально
fk0>не являются кодом. Например шаблоны. Как шаблон может быть в CPP, какой в этом смысл?
fk0>Шаблон -- это сущность лежащая в своём совершенно ортогональном пространстве шаблонов,
fk0>которое ортогонально пространствам типов и "вещественных" объектов таких как переменные
fk0>и функции.

При использовании модулей шаблоны как раз нормально размещаются в .cpp файлах.

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

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

S>>Есть ещё виртуальные методы. При оверрайде их в классах наследниках приходится повторно прописывать те же аргументы по несколько раз. И при изменении в базовом классе тянуть все изменения везде.

fk0> А если бы ты так не делал, то как компилятор бы отличал виртуальные методы от других
fk0>перегруженных функций с тем же именем? А никак. Тогда нужно забыть об ADL (argument
fk0>dependent lookup). А это важное свойство C++ которого нет у многих других.

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

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

MA>> Публичный контракт из C# или Java получить совершенно точно не представляется возможным, пока вы не выполните работу компилятора.
N>Хм, как правило в этих обоих языках _публичный_ контракт выделяют в виде сущности типа interface. По крайней мере так ну очень рекомендуется. А уже отнаследоваться от интерфейса — сделать реализацию — можно и только на нужные методы.
N>Конечно, никто не заставляет так делать, и внутри пакетов на это поплёвывают.
Библиотеки, обычно не делают интерфейсы на каждый публичный тип, т.к. в этом, часто просто нет смысла (исходя из использования).
Да, это частично парируется, в C#, например, ч.з. internal interface. Но всё таки, добавлять это только лишь для организации кода — врядли будет нормальным, с точки зрения рантайма или общепринятых практик.
А для структур и вовсе надо 3 раза подумать, прежде чем наделить её (публичным) интерфейсом.

MA>> В реальности — в проектах — есть одна директория куда навалено по заветам FDG — т.е. все в одну кучу,
N>Реально есть такой завет?
Не думаю, что есть прямые заветы про директории — есть заветы про нэймспейсы (что вполне обоснованно).
Но студия, из коробки, считает, что структура директорий и нэймспейсов совпадают, что приводит, к тому что или проекты тупо следуют этому правилу, либо мудрят что-то руками (например свои шаблоны, правильные экстеншны эту мелочь решают — но оба вариант на любителя, а в самой студии/проектной системе всё никак не сделают настройку, хотя и просят уже много лет).
В последнее время, сверху этого появился такой вот анализатор: dotnet_style_namespace_match_folder, так что при должном усердии, это можно ещё и превратить в ошибку компиляции.

MA>> и если вы это видите все в первый десяток раз — то никакие средства IDE — не помогут, не говоря уже о том, что IDE нужна когда нужна но не более. А если код логически расформирован — то внезапно уже и IDE не нужна что бы понять что и где.
N>Ну при определённом уровне сложности с IDE таки в разы легче

Потенциальную пользу от IDE я не отрицаю, да и всех я не видел всё равно. В студии есть очень много хорошего, и иногда пользуюсь, хотя есть и досадные баги.

N>Я конечно извиняюсь, и не придирка, но: https://dictionary.cambridge.org/dictionary/english/header
N>Ну нету там "и".
Спасибо, принято.

По русски это всё равно правильно писать не так.

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

fk0> А то заладили, модули, модули. И будет то же самое. И, кстати, в C# есть понятие .ref
fk0>файлов и в них те же "хедеры". В студии по F11/F12 оно кстати показывать их умеет...
reference assemblies — это трюк компилятора, служащий только для того, что бы компилятор не грузил реальные сборки во время компиляции.
Т.е. в любом случае они не учавствуют в компиляции кода самой сборки, и соответственно они не используются для валидации её как таковой.
Да и на сегодня — они генерируются автоматически (прямо сборки), как продукт компиляции, которая потом легко залетит в nuget-пакет, опять таки, ради оптимизиации потребления пакетов.
Со стороны выглядит похоже, но служит другим целям.

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

M>>1) часто на сервере нужно править исходники. Там только текстовый терминал.

AS>Шта?

AS>Какой сервер? К чему он указан? Мы точно про С++ говорим?)

Как раз для софта на C++ такое вероятнее, чем на многих других языках.
Причём часто сервер одновременно embedded в смысле малых ресурсов.

M>>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.
AS>Все ИДЕ имеют хоткеи, дублирующие функциональность мышки. И серьёзно — упомянутая разница в скорости работы с мышкой\клавиатурой в процессе разработки не важна в принципе.

Зато графика в сотни раз прожорливее по трафику.

Хотя это нивелируется тем, что в некоторых IDE можно сделать ремотное управление по ssh+gdb...

M>>4) И намного удобнее когда 1 файл = 1 класс.
AS>Это говорит только о небольшом опыте работы с С++. Есть свои ньюансы. В большинстве случаев всё же удобнее разделение по файлам из-за анонимных неймспейсов и управлением вложениями классов.

Так разделение по какому принципу-то?

AS>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс.

Её надо по-вашему запускать на целевом хосте, или как?

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

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

M>>У меня большой опыт как на с/с++, так и на c#.
M>>На c# намного удобнее читать/писать бизнес логигу (или другую логику, где много разных сущностей и классов), так как не приходиться лазить по 2-м файлам, а всё можно исправить и увидеть в одном файле.

fk0> Во-первых не в одном. Там есть partial классы и потом концов не найдёшь, не то, что не в одном
fk0>файле, а вообще непонятно даже в какой DLL-ке...
но это же не обязательная фича и используется только там где надо(на моей памяти, так обычно делили авто-генерённый код и ручной). Лежит в той же сборке

fk0> Во-вторых чем оно удобно, когда есть файл на 50000 строк и там всё вперемешку.
fk0>Без IDE по такому файлу навигация невозможна, а если ты код поменял, пока редактировал,
fk0>что он стал синтаксически некорректным (скобок не хватает), то и IDE развалится и
fk0>перестанет работать... Сомнительное удобство.

ага, но зачем такое длинное?
если у вас файлы по 50 тысяч строк, .h файл вам не поможет.

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

MA> Со стороны выглядит похоже, но служит другим целям.

Каким? И чем это отличается от плюсовых хидеров? Тем, что генерятся автоматически?

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

S>При использовании модулей шаблоны как раз нормально размещаются в .cpp файлах.

А чем тогда эти .cpp файлы отличаются от .h файлов?

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

MA>> Со стороны выглядит похоже, но служит другим целям.

M>Каким? И чем это отличается от плюсовых хидеров? Тем, что генерятся автоматически?
Тем, что это исключительно служит целям оптимизации процесса компиляции (скорость, память и т.п. — ему банально нужно будет грузить/молотить меньше, и сервер компилятора будет держать меньше памяти в итоге).
Тем, что это позволяет иметь "targeting pack" не имея реальных сборок которые могут быть использованы в рантайме (так, имея установленный .NET 4.8, мы легко можем таргетится на .NET 4.5), но в рантайме мы всегда используем 4.8.
Тем, что это это изначально вызвано не сколько причинами выше, а тем, что .NET 4.x и BCL имеют достаточно интересную стратегию деплоймента (in-place), которая решила одни проблемы, но породила другие.

От плюсовых заголовков это отличается тем, что это не является частью языка. Reference assembly — это обычная сборка (.dll), откуда удалены все незначимые метаданные и детали. Т.е. тел методов нет, и доступны только публичные типы. Точно так же вместо этого можно использовать реальные сборки, как это и делалось ~10 лет назад, абсолютно ничего не потеряв.
А в рамках одной сборки (assembly) — это вообще не нужно. Это даже не нужно в рамках одного солюшена с сотней проектов.

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

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

M>>>1) часто на сервере нужно править исходники. Там только текстовый терминал.

AS>>Шта?

AS>>Какой сервер? К чему он указан? Мы точно про С++ говорим?)

N>Как раз для софта на C++ такое вероятнее, чем на многих других языках.
N>Причём часто сервер одновременно embedded в смысле малых ресурсов.

Вообще невероятно, из раздела особо фантастичной фантастики.
Про embedded — это вообще файспалм.
Я понимаю, что про С++ ходит много слухов, но всё на самом деле не так

M>>>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.
AS>>Все ИДЕ имеют хоткеи, дублирующие функциональность мышки. И серьёзно — упомянутая разница в скорости работы с мышкой\клавиатурой в процессе разработки не важна в принципе.
N>Зато графика в сотни раз прожорливее по трафику.
N>Хотя это нивелируется тем, что в некоторых IDE можно сделать ремотное управление по ssh+gdb...

Это всё из разряда "сделать из буханки троллейбус". Вы выдумываете проблемы, которых в реальной жизни у разработки на С++ не существует.

AS>>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс.
N>Её надо по-вашему запускать на целевом хосте, или как?

... не могу понять — это прикол или серьезно спрашивате?)

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

M>>>>1) часто на сервере нужно править исходники. Там только текстовый терминал.

AS>>>Шта?

AS>>>Какой сервер? К чему он указан? Мы точно про С++ говорим?)

N>>Как раз для софта на C++ такое вероятнее, чем на многих других языках.
N>>Причём часто сервер одновременно embedded в смысле малых ресурсов.

AS>Вообще невероятно, из раздела особо фантастичной фантастики.
AS>Про embedded — это вообще файспалм.
AS>Я понимаю, что про С++ ходит много слухов, но всё на самом деле не так

Ну то есть вы единственный кто с C++ работает, а остальные слухами кормятся? Да, понятно. Только вот интересно, с каким это я языком работаю последние лет 7 достаточно плотно, а то называется он почему-то точно так же, выглядит точно так же, а оказывается совершенно другой...

(А с C — 24 почти непрерывно, для сравнения. Лучше считать этот срок, наверно, потому что фишки C++ тут не принципиальны.)

M>>>>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее.
AS>>>Все ИДЕ имеют хоткеи, дублирующие функциональность мышки. И серьёзно — упомянутая разница в скорости работы с мышкой\клавиатурой в процессе разработки не важна в принципе.
N>>Зато графика в сотни раз прожорливее по трафику.
N>>Хотя это нивелируется тем, что в некоторых IDE можно сделать ремотное управление по ssh+gdb...
AS>Это всё из разряда "сделать из буханки троллейбус". Вы выдумываете проблемы, которых в реальной жизни у разработки на С++ не существует.

Ну вот я и говорю — какая-то жизнь одновременно реальная (у меня) и нереальная (у вас). Простите, как ваша планета зовётся?

(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)

AS>>>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс.
N>>Её надо по-вашему запускать на целевом хосте, или как?

AS>

AS>... не могу понять — это прикол или серьезно спрашивате?)

Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?

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

N>Ну то есть вы единственный кто с C++ работает, а остальные слухами кормятся? Да, понятно. Только вот интересно, с каким это я языком работаю последние лет 7 достаточно плотно, а то называется он почему-то точно так же, выглядит точно так же, а оказывается совершенно другой...

Видимо да, вы что-то другое делаете и путаете что-то. Так как на С++ на embedded никто не разрабатывает в силу ряда причин, которые выходят за рамки топика. Для этих целей используют кросс-компиляцию.

AS>>>>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс.
N>>>Её надо по-вашему запускать на целевом хосте, или как?

AS>>

AS>>... не могу понять — это прикол или серьезно спрашивате?)

N>Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?

Софт на С++ в 100% случаев работает на нескольких железках\серверах\телефонах\ и т.д.
Вопрос — вы заново пишите код на каждом устройстве?

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

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

N>(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)

Да нет у С++ никакого аварийного режима с правкой исходников на целевом устройстве.
Это же классический троллейбус из буханки.
Это всё мифы перекочевавшие от админов о "горячей правке конфигов на проде". Оно никаким боком не мапится на С++.

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

AS>Видимо да, вы что-то другое делаете и путаете что-то. Так как на С++ на embedded никто не разрабатывает в силу ряда причин, которые выходят за рамки топика. Для этих целей используют кросс-компиляцию.

В последнем случае, который я вспоминал, было прокси, сидящее где-то у чёрта на куличках в хитроватой железяке и ещё и в контейнере, как сейчас модно, с доступом через три ssh, диска было что-то вроде 40MB, оперативки сравнимо, и компилировать там уже было нереально — а вот влить целиком результат компиляции (с исходниками) и напустить gdb вживую — это как раз то, что помогло поймать ситуацию "пакет шмяк, данные жмяк, zzz event бздынь, важное поле пшшшш, исполнение бряк, о, я вижу проблемные данные!"
Но если бы ресурсов было чуть побольше, как на QA стенде — то и компиляцию бы туда завели без проблем, и CLion какой-нибудь прокинули на remote host всё исполнять аж бегом — и так тоже делали.
В стабильном варианте для юзеров, конечно, всё это пакетируется и контейнеризуется, там не то что gcc, там less не найдёшь без лома и топора. А вот ловить расставив 100500 отладок — чем легче это сделать на месте, тем быстрее...

А у коллеги, вероятно, и контейнеризации нет. В ISP я в основном так делал — но там у меня по стандартной схеме pets vs. cattle были таки pets. Сейчас у юзеров у нас такое не водится, всё-таки повторяемость devops-процесса вкусна переносимостью опыта.

N>>Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?

AS>Софт на С++ в 100% случаев работает на нескольких железках\серверах\телефонах\ и т.д.
AS>Вопрос — вы заново пишите код на каждом устройстве?

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

AS>Советую что-нибудь почитать про системы контроля версий, билд-системы, системы непрерывной интеграции и т.п.
AS>И вообще про то как разрабатывать софт на С++.
AS>И тогда таких странных вопросов у вас не будет.

Не считайте себя единственным знатоком названных вами страшных слов

И до седмижды повторяю: даже там, где основной путь лежит через все эти системы, остаётся 1% на всякое непредвиденное. Главное, чтобы таки не больше 1%.

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

N>>(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)

AS>Да нет у С++ никакого аварийного режима с правкой исходников на целевом устройстве.

У C++ нет, он язык и компилятор. У конкретной софтины в конкретном месте вполне может быть, и происходило неоднократно совсем недавно, ещё детали не стёрлись.

AS>Это же классический троллейбус из буханки.
AS>Это всё мифы перекочевавшие от админов о "горячей правке конфигов на проде". Оно никаким боком не мапится на С++.

Года не прошло с конкретной реализации этого "мифа".

M>А чем тогда эти .cpp файлы отличаются от .h файлов?
Ничем, кроме имени файла.

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

N>В последнем случае, который я вспоминал, было прокси, сидящее где-то у чёрта на куличках в хитроватой железяке и ещё и в контейнере, как сейчас модно, с доступом через три ssh, диска было что-то вроде 40MB, оперативки сравнимо, и компилировать там уже было нереально — а вот влить целиком результат компиляции (с исходниками) и напустить gdb вживую — это как раз то, что помогло поймать ситуацию "пакет шмяк, данные жмяк, zzz event бздынь, важное поле пшшшш, исполнение бряк, о, я вижу проблемные данные!"
N>Но если бы ресурсов было чуть побольше, как на QA стенде — то и компиляцию бы туда завели без проблем, и CLion какой-нибудь прокинули на remote host всё исполнять аж бегом — и так тоже делали.
N>В стабильном варианте для юзеров, конечно, всё это пакетируется и контейнеризуется, там не то что gcc, там less не найдёшь без лома и топора. А вот ловить расставив 100500 отладок — чем легче это сделать на месте, тем быстрее...

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

N>Ну вы таки почему-то отказались понимать изначально, что это всё про специализированный патчинг на месте и про отладку. Хотя можно было просто спросить.

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

А с отладкой ни в каком режиме проблем нет.

N>И до седмижды повторяю: даже там, где основной путь лежит через все эти системы, остаётся 1% на всякое непредвиденное. Главное, чтобы таки не больше 1%.

А я ещё раз настаиваю, что нет даже 1% непредвиденного, чтобы использовать то извращение, что вы предлагаете (держать исходники на целевой\целевых продакт машинах и там билдить).
Ни один менеджер не возьмёт на себя такие риски с нарушением всех инженерных подходов при разработке софта ради непонятно чего.

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

AS>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.
AS>Никакого "хотфикса" а-ля "зайти по цепочке ssh по диалапу на северном полюсе и на месте поправить исходники, собрать и задеплоить" в С++ разработке нет от слова вообще.

"Блажен кто верует, тепло ему на свете" (c).

AS>С++ это не скриптовый язык, никакого патчинга в нём никто не делает. При проблеме делается реверт на предыдущий бинарник и вставляется пистон всем ответственным за провтык. Потом, после доработки, выкатывается пофикшенная версия в стандартном режиме.
AS>Потому что С++ код несколько сложнее однострочного скрипта одмина.

Аналогично.

AS>А я ещё раз настаиваю, что нет даже 1% непредвиденного, чтобы использовать то извращение, что вы предлагаете (держать исходники на целевой\целевых продакт машинах и там билдить).
AS>Ни один менеджер не возьмёт на себя такие риски с нарушением всех инженерных подходов при разработке софта ради непонятно чего.

Безусловно понятно чего.

AS>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.

Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?

я лично работаю
msvc и clang нужный мне функционал без проблем поддерживает
для линукса, видел что и gcc тоже поддерживает, но нужный мне функционал еще не проверял
но даже если и не будет поддерживать, возьму clang

и да, по меньше заглядывайте в https://en.cppreference.com/w/cpp/compiler_support/20
оно не всегда актуально

нужные мне фиксы для некоторых С++20 features
там до сих пор partial
хотя в clang уже как минимум два релиза назад заработали, хотя issues на них висят все еще открытыми

Здравствуйте, maks1180,

M>Для меня основной минус с++
Плюсы веделяются своей историей, и возникшей в связи с этим уже философией. Причем вот мне почему-то кажется точно не без юмора. Т.е. это когда пережив множество историй, можно немного потратить время на одну из них, одна из последних и интересных — некое зависание комитета по стандартизации, от чего случилась некая рЭволюционная ситуация "верхи — не хотят, а низы не могут", низы именно уже не могли.. ждать. Ну а поскольку в плюсы пробралось достаточно много интуитивных α-самцов, низы проломили дно снизу, вверх,... и вот привет, на те boost. Ну я не знаю, как такое можно было замутить где-то в каком нить фреймворке в шарпах, но у нас народ решительный. И первый культурный привет, который я помню — это был compile time typeof участника данного форума, чистый хакинг, как раз в мелочах относительно включаемых шаблонных классов. Потом много было чего интересного.
Но что хочется заметить, что когда слушаешь Страуструпа, то можно почерпнуть, ну кроме плюсового контекста, допустим фразу "без блэкборда не скажу". Вот сидишь ты допустим в стеке задачи, глубоооком таком, минут 15 лично мне только на вкручивание всего контекста в свой уже стек, и приходит приходящий, и ты упс, выпустить жалко, его — стек, а приходящий, ну на столько приходящий, что понимаешь, что этот кандидат математических наук, решил, что я его дипломный руководитель, акстись, — у мине четыре коридорных, не мешай, .. — и на автомате — "без блэкборда не скажу", а в наушники тебе в это время, Монк как говорят иногда музыканты — Фелониус, в фоне. И с перепугу хвать, а где стек? А, воот не потерял, хвост как гвоорится в руках, значит — харрошая фраза, умный человек ведь сказал целый Страуструп. Вот так.
В общем, и целом, — нормально у нас все с плюсами, просто прекрасно. У нас там полный джаз, да, я помню, как мне один джавист на проекте, на котором он кричал, что нет AI, а проект nlp-шный с языком для NLP (просто мой хороший друг не дочитал, что AI есть и для nlp и не обязательно аппроксимационный). Вот он говорил также, что наши шаблоны открыли "как остров", и знаете. Я согласен, джаз тоже так открывали, играют и хотьбыхны, — цвету кожи, неакедимичности, необразованности, .. но зарвались. Забыли отцов основателей.
По делу мне сказать конкретно нечего, после моей извращенной часто практики, где хватаются за все, получается в препроцессоре — делаешь в препроцессоре, получается в шаблонах — вперед. Я вот одного не понимаю, че все пристали к этому бедному препроцессору, хорошая вещь, там столько хороших и ценных практик, что... а — давайте засунем его в АСТ, прям вот не только в llvm. А что ??
Коллеги, на самом деле, мы уже, зрелые ткскть программисты, верим, в то, что ... ну понятно, что хрустит оно тоже, но еще оно и должно быть вкусно. Прежде всего, вот как хамон с пивом. НУ или как допустим бемша свинг сыгранная медески трио (не монком), именно так надо постигать такие темы) тогда и плюсы сказкой будут. ээх хаживал тут иногда, чувак похожий .. джаззер мол. Даже знаете кого ? Колтрейна гиант степ играл, ну ..мне колтрейн просто не оч .. духовики, слишком много звуку отдают, если круто звучит майлс девис (им нравится именно звук трубы, такой тооонкий). Но вообще мы за плюсы. Не надо наездов — лучше предлрожите как добавить
c-time-рефлекшин, тока оно мне ужежь не надо, тут столько вариантов было по нему

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

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

S>>При использовании модулей шаблоны как раз нормально размещаются в .cpp файлах.

M>А чем тогда эти .cpp файлы отличаются от .h файлов?

Когда ты инклюдишь .h то компилятор его парсит заново каждый раз.

Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее.

Можно даже из STL инклюдов делать модули и импортировать через:
import <iostream>;
И компилятор уже не будет парсить их тоже.

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

Да, мне говорили, что я Капитан Очевидность.

S>Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее.
А чем это отличается от древней статической либы? Которая по сути просто пачка объектников в одном файле.

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

AS>>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.

M>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?

Ну у меня на прошлой работе было именно так (на текущей ещё не добрался до подробностей). Тут совершенно не секрет — portaone.com, поставка VoIP appliances с биллингом, софтсвичом и сопутствующими компонентами. Разработка ведётся на чём хочешь, но итого софт должен быть проверен на базовые проблемы самим разработчиком на виртуалках, которые реализуют сжатую в один хост полную систему (для особых случаев — в 2-3 хоста), поэтому в зависимости от персональных вкусов используется какой-то ремотный вариант управления из IDE (я брал CLion) или без него (шелл+vim+make уже пригодно во многих случаях). Потом проверка в CI (два набора тестов — от самих девелов и от QA), ревью коллегами, влив в целевую ветку, проверка уже вручную в QA и, если всё хорошо, официальный релиз ветки, а с неё нарезаются инсталляционные и обновительные комплекты (делают девопы из отдела релизов), в виде инсталлятов (загрузочный ISO+USB) и репозитория пакетов (для yum). Софт ставится (набор rpm-пакетиков согласно роли конкретного хоста) и конфигурится (сложная система, прописывает 100500 параметров), и идёт работать. В нормальном режиме девелы не имеют доступа к клиенту, имеет только саппорт через определённые процедуры.
Подробнее в доках на сайте, если интересно.

Это основной путь, который должен соблюдаться по максимуму, но если особая проблема — то включаются и особые процедуры вплоть до доступа на систему клиента с патчингом и сборкой на ней. Вот у меня за последние три года было штуки 4 таких случаев.
Принципиально, что после того, как всё удовлетворено и клиент подтвердил исправление, начинается разбор полётов — код бэкапится, сравнивается с базовой веткой, очищается от дебажной печати, девелопер должен описать в тикет проблему и результаты, по необходимости создаются тикеты на другие вскрытые проблемы...

Что там у коллеги AeroSun, не знаю, но обобщает он совершенно неадекватно. Видимо, опыт в 1-2 проекта специфической направленности не даёт больше данных.

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

S>>Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее.
V>А чем это отличается от древней статической либы? Которая по сути просто пачка объектников в одном файле.

Тем, что .lib идут в пачке с .h (которые опять же парсятся при инклюде).

А тут только .cpp и никакие .h уже не нужны для импорта.

Но если надо один модуль разделить на файлы, то это делается через партишены. ( имя_модуля:имя_партишена )

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

M>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?

Я подозреваю, что опыта у меня минимум на 10 лет больше всех присутствующих. Опыт есть практически во всех отраслях и со всем чем можно (от ембедед до систем на докере)

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

Скажем, если бы у меня в отделе появился чел с подобной идеей — то первыми вопросами было бы:
1) Может человеку стоит взять отпуск — заработался?
2) кто возьмет на себя ответственность в случае чего?
3) Кто заплатит за время когда разработчик занимается непонятно чем вместо продолжения выполнения своей работы?
4) Если есть секьюрность — то что предлагает и по какому праву в разработчик в таком случае?

Ещё раз — в С++ такого изврата в принципе нет. Делается откат на предыдущий бинарник и начинается разбор полётов. Исправленная версия выкатывается в обычном режиме.
И уж абсолютно никто не держит исходники на целевом устройстве. А идея компилить их в ембедед — это вообще за гранью понимания разработки на С++

M>>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?

AS>Я подозреваю, что опыта у меня минимум на 10 лет больше всех присутствующих. Опыт есть практически во всех отраслях и со всем чем можно (от ембедед до систем на докере)

Вы не ответили на вопрос где вы так работаете, что у вас целый специальный отдел делает билд ?
Я вот работал в Майкрософте (США, редмонт) 13 лет назад, даже там я такого не видел...

AS>И уж абсолютно никто не держит исходники на целевом устройстве.

С чего вы решили что можете утверждать за всех людей на планете ? Я знаю несколько человек кто держит исходники — значит вы НЕ правы.

MA>В общем, минус .h файлов — он же и его плюс. Если .h файлы хорошо оформлены — то с таким кодом, очень приятно работать.

Читать только приятнее, и то не всегда, например значение аргументов (функции) по умолчанию написаны только в h файле, и поэтому в cpp их вообще не видно.
Менять же без IDE жутко неудобно в 2-х местах нужно это делать.

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы:
M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.

В таких случаях я применяю "интерфейс" (для C++ это абстрактный базовый класс):
https://stackoverflow.com/questions/9756893/how-to-implement-interfaces-in-c
Тогда класс A будет использовать InterfaceB (базовый класс для B) вместо непосредственно класса B.

M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.

Зачем использовать макрос #define, если давно уже есть constexpr:
https://rules.sonarsource.com/cpp/RSPEC-5028
https://devblogs.microsoft.com/cppblog/convert-macros-to-constexpr
https://stackoverflow.com/questions/42388077/constexpr-vs-macros

Для более сложных случаев, вместо макроопределения для функций/типов — применяю ключевое слово using (как задание алиаса для пользовательских типов данных):
https://en.cppreference.com/w/cpp/language/type_alias

M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?

Это не проблемы.
Что же касается названия и аргументов функций, то лббая IDE решает данные вопросы.

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

V>>Вообще это плюс. В хидере у тебя интерфейс, в сишнике имплементация.

M>Да, только все современные языки такие как C#, Java ушли от этого "так называемого плюса".

Вот только в Java и в C# (из-за этого "ушли") уровень вложенности пар фигурных скобок — просто зашкаливает.
Иногда — смотришь в то же окошко IntelliJ IDEA (Java) — думаешь: как же в плюсах всё просто сделано...

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

M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода.
M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.

Это далеко не основной минус С++. У С++ огромное количество разнообразных минусов, граблей и костылей. Люди с 20 годами опыта периодически продолжают открывать для себя все новые и новые грабли, наступая на них, зато сколько возможностей и новых открытий. За это мы и любим и одновременно ненавидим С++.

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

N>У C++ нет, он язык и компилятор. У конкретной софтины в конкретном месте вполне может быть, и происходило неоднократно совсем недавно, ещё детали не стёрлись.
Наличие С++ тулчейна на целевой платформе это большое исключение, особенно если это embedded. В мире всякое бывает, но это действительно очень крайний случай.

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

Да ладно. Минус один, а плюсов все же два.

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

M>Читать только приятнее, и то не всегда, например значение аргументов (функции) по умолчанию написаны только в h файле, и поэтому в cpp их вообще не видно.
M>Менять же без IDE жутко неудобно в 2-х местах нужно это делать.
О, это-то неудобно? Неудобно это когда у вас есть с пяток перегрузок, все из них — по сути просто шлюзы передающие значения по умолчанию. Чтение документации вообще никак не говорит, какое из них конкретно будет передано. И единственный способ узнать точно — полезть собственно в исходники (и благо когда они есть).
Ну а в общем — а зачем в реализации знать значение по умолчанию? Она должна работать и без этого как бы.

	От:	maks1180
	Дата:	24.12.21 09:41
	Оценка:	+1 -1

	От:	σ
	Дата:	24.12.21 10:02
	Оценка:

	От:	Alexander G
	Дата:	24.12.21 10:03
	Оценка:

	От:	удусекшл
	Дата:	24.12.21 10:21
	Оценка:	+1

	От:	ArtDenis
	Дата:	24.12.21 10:25
	Оценка:	+9

От:	netch80	http://netch80.dreamwidth.org/
Дата:	24.12.21 11:04
Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	24.12.21 11:23
Оценка:

	От:	Mystic Artifact
	Дата:	24.12.21 18:15
	Оценка:	+7

От:	reversecode	google
Дата:	24.12.21 18:52
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	24.12.21 20:19
Оценка:	-2

От:	fk0	https://fk0.name
Дата:	25.12.21 14:41
Оценка:

От:	sept_tone	https://youtube.com/shorts/eapWB7W8hEE
Дата:	27.12.21 04:13
Оценка:

	От:	Pavel Dvorkin
	Дата:	02.01.22 15:37
	Оценка:	+2