Здравствуйте, kov_serg, Вы писали:
SP>>так в системах вёрстки здорового человека (latex например) оглавление и предметные указатели формируются автоматически. _>Ага после нескольких проходов
Ну ты же не сам ногами их делаешь десятикилометровыми кругами
Здравствуйте, maks1180, Вы писали:
M>>Современные IDE умеют одним кликом мышки заводить новые классы, добавлять новые функции и члены класса сразу и в хедерах и в исходниках. Так же переименовывать сразу во всех исходниках (у них это в разделе "Рефакторинг" в выпадающем меню)
M>Это да: M>1) часто на сервере нужно править исходники. Там только текстовый терминал.
Текстовый терминал Бро, я в кейле, сидя на пыхтящем роботе, бьющем гусеницой, на ходу правлю баги и отлаживаю прошивку. А ты — терминал, терминал...
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 файл.
Здравствуйте, LaptevVV, Вы писали:
M>>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода. M>>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах. LVV> LVV>Я с этим столкнулся еще в 1992 году...
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
Если вы разберётесь с модулями и с партишенами, то поймёте что это здорово. Можно чётко контролировать что конкретно экспортируется и куда.
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 разных местах скопипасчены.
Здравствуйте, T4r4sB, Вы писали:
M>>Никому не надо, все осилили то, что есть. Если не осилил — сделай. Хотя ты и это не осилишь
TB>Что с тобой случилось? Почему от тебя на форуме столько негатива? Ты чем-то болеешь?
От меня? Много негатива? Это ты ещё не видел ответы reversecode'а
Но вообще — какие-то через-чур наивные вопросы, от человека, который сто лет тут обитает и пишет на плюсах
